The collapsing economy forces the companies to pay more attention to required capabilities for a successful offshoring strategy and that they have higher demands of offshoring service providers.

Our experience points out that three aspects determine the success of every offshoring strategy.

• Collaborate withother cultures;
• Bridge the gap with a Bridge SE;
•  A well thought offshore outsourcing plan. 

A.    Think through the aspects of collaboating with other cultures

Najete M’Bata, partner of Slagkracht Management has developed an easy method for dealing with other cultures. By applying her six universal basic principles you are capable of thinking, looking and handle beyond the ‘borders’ of every culture. The six principles are:

1. Be aware of the prejudices that exist in other cultures about the Netherlands and the Dutch existence and be aware of your own prejudices about the other culture.
2. Learn about differences and similarities of cultures.
3. Observe other viewpoints.
4. Show respect. Respect if business is going different than you are used to. Different is not the same as ‘wrong’.
5. Carefully choose a form of communication which helps to achieve your goal.
6. Integrate, make a bridge on business level, relationship level, communication level, logistic level, cultural level, linguistic level.

‘Only by moving as much as possible work to low-income countries like India, Dutch ICT-businesses can keep their head above the water.’

Do you agree with this theorem and why?

My answer is ‘yes and no’. We offer offshoring services ourselves and I understand the thought behind the question. The situation is not really black and white I think. It is good for businesses to replace their work to low-income countries for a couple of reasons. The most important one is access to talent. Second reason is saving on costs. Companies can flower because they have smart people working for them who can produce smart products. If a company can find these people in local areas and produce these smart products against a competitive price, the urge to replace work will be less or won’t be even there. But if the competition can create the same product against a much lower price by working for the greatest part with cheaper people, it will be fatal for that organization.

The biggest problem however is to find talent in the Netherlands. Especially when we’re talking about technical people and in specific the ICT programmers. If an organization can’t find people that can deliver smart products, the organization won’t last long. The smart products can also be made with less people by organizing things more efficiently, but you will always need people. So you can also bring the people to the Netherlands.

So the ‘yes’ is two-sided: if it is hard for an organization to find people, while these people are necessary for making the product and to let the organization grow, you will have to look across borders. When the competition uses much offshore or nearshore people and by that attracting more talent with it and producing more cheap, the urge will be bigger to do so as well.

The ‘no’ is probably weird coming from somebody who offers offshoring services but it has to do with the theorem. Not everything can be done offshore. I think it won’t be a goal to ‘replace as much as possible work offshore’ but to replace the amount of work where it is hard to find people for in the Netherlands. Or were the necessity is great to save of the costs. In addition, cost-saving as a starting point is also a ‘problem’. To set up offshoring successfully, the right people offshore and onshore have to be deployed, who can also build up a proper routine. This takes time. Salaries offshore and nearshore are also rising due to increasing demands for talent. Saving on the costs is therefore sometimes disappointing. So it is better to have the goal to ‘attract talent’ or ‘faster upscaling’ or ‘launch products faster’.

Conclusion: that there is a shortage of IT professionals and then especially programmers in the Netherlands seems a fact. That more and more companies move their work offshore also seems to be a trend that is unstoppable. As the market moves in that direction, it seems necessary for companies to also move work itself. At the same time, for a specific company with a specific product it can be wiser to not (directly) move work offshore. 

A large number of organizations only choose to outsource because they want to lower the cost of production and other types of business expenses such as customer service and IT services.  

The great thing about outsourcing is not only because it helps lower your business expenses; outsourcing offers a whole lot of other advantages to business owners. Yes, most business owners will embrace outsourcing tightly because it offers them the opportunity to lower overhead expenses of running their business.  Outsourcing will also offer them the chance to cut down on the number of people who are virtually useless and are on the payroll (getting paid to do absolutely NOTHING!), taxes, utilities, insurance and so on.

Outsourcing will also offer you the opportunity to invest all the money that you have saved on overhead and other operational expenses into other areas of business that you have been dying to venture into.

Outsourcing also offers you the chance to take better control of your company. Because outsourcing will considerable lower the number your employees, you can now manage them more effectively. You will be able to make your staff more accountable to their actions in the company.

With outsourcing, you will be able to pay more attention to your core competencies and take your company to a whole new level. By simply taking other important but less nagging work activities out of the way, you will be able to plan effectively and sell your products and or services better – thus, increasing the efficiency of your company’s marketing capabilities.

Another benefit of outsourcing is having the choice of moving certain work tasks to an offshore service provider that is specialized in that area. This means that you can increase the quality of your service or products by simply finding a competent outsourcing partner that has exceptional expertise. You do not have to worry yourself about shelling out money to train new employees (who by the way will leave your company in a heartbeat when they get a better offer elsewhere) and set up new office space, amenities and so on.

You can now tell just how well you will benefit from outsourcing some of your company’s work activities to outsourcing professionals. The major aim of outsourcing is to ensure your business’ global competitiveness. Though, it may seem pretty absurd; lowering the number of in-house employees may actually make your company stronger.

So, lemme ask you now; are you taking advantage of outsourcing? 

To learn more about outsourcing and get your free copy of my book, ‘Outsource This!’ visit http://www.123Employee.com.

What inspired me in the book is that Zappos took something which is to me somehow inherently ‘boring’ (selling shoes through a website) and grew it into a business that is all about ‘company culture’, ‘core values’ and ‘happiness’. Just read the ten core values of Zappos and you can see that there is emotion in it, they sound and feel inspiring. The way Tony Hiesh described the connection between their service and happiness: ‘We’ve always had customers tell us that they think of the experience of opening up a Zappos shipment as ‘Happiness in a Box’. Whether it’s the happiness that customers feel when they receive the perfect pair of shoes or the perfect outfit, or the happiness that customers feel from our surprise upgrades to overnight shipping or when they talk to someone on our Customer Loyaly Team, or the happiness that employees feel from being part of a culture whose values match their own personal values – the thing that ties all of these things together is happiness‘.

The question underlying getting happiness from business (which is an outcome) is ‘why?’. Why are we in this business? Why do we do what we do? 

We’ve thought a lot about these questions within Bridge the past years. Some thoughts havecome up lately. One of my Indian colleagues (Sanjay) put it this way: ‘each client comes to us with a dream and we help them achieve this’.John, our Swedish sales-machine said, let’s cut all the crap, I believe that the essence of what we’re doing is to make it possible for people globally spread to work together, have fun together and to make great results together! It is about fun and making the gap smaller.

For me the why is at the core about creating a better balance in the world. I strongly believe that offshoring is an effective way to fight poverty. We create jobs in developing countries (in our case India and Ukraine). The people working for us get a good salary, which they use to provide their families with a good living. At the same time, vacancies that are hard to fill in Europe because there are not enough people, are more easily filled and companies in the West grow, create more profit and eventually create jobs in the West as well.

On top of this why there are more answers to the why. Every day I sit behind my pc, which I see as my ‘window to the world’. I talk to people from all over the world, linking human beings from one country with humans from other countries. They work together to accomplish ‘stuff’ together. Accomplishing things together brings happiness. Working together with ‘nice guys’ brings happiness. Putting cake in each others face  and throwing colors at each other brings happiness (Maslow would say it’s only pleasure, not happiness but in our company we keep repeating the same joke, so it’s long term ). It makes me happy if I see that what we’ve learned in the past 8 years on how to make global cooperation’s work, works for our customers.

Maybe we should refer to this not as ‘happiness in a box’ but ‘happiness through a wire’.

These were my thoughts on happiness in our business. I wonder what are yours…

 Are retrospectives difficult? No! Are they valuable? Certainly! But you have to know how to do them, to turn them into an effective tool for continuous improvement.

Why do Retrospectives?

Let’s first start by understanding why you would want to do them. The Agile Manifesto provides us with a couple of good reasons. It starts with the first sentence of the manifesto:

“Uncovering better ways” tells me that there isn’t 1 solution, not 1 best way, or silver bullet to do software development. And since we are uncovering it, we will have to try things and reflect to see how it works. This is where retrospectives come in, as a way to reflect at the end of the sprint to see how the team has been doing their work. And to uncover what worked, and what didn’t. Having an agile mindset means that you want to reflect and learn, and keep on reflecting and learning. You’re never done!

And then there are also the principles behind the Agile Manifesto. The 12th principle says: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” It is often called “inspect and adapt”, which start by doing things, learn, and improve along the way. Just like you don’t know all requirements up front when you start developing a product, you start working with what is clear and needed and then change based upon the feedback. Retrospectives are a way to “embrace change” in the way you work as a team.

Retrospectives aren’t something that agile or Scrum has invented. Getting feedback to improve yourself is much older. Actually, even project management methods like Prince-2 and the PMBoK has reflection included in the way that they propose to manage projects. What Scrum has done is to define a ritual to do the reflection, and to give it a clear spot in the software development cycle. 

How to do Retrospectives

So now that we understand why to do retrospectives, let’s discuss how to do them. What I have found to be very important in having effective retrospectives is that the right culture is set at the start. I use the Prime Directive to assure that a retrospective is a positive and fruitful event. It states: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”. With the Prime Directive, a retrospective becomes an effective team gathering to learn and find solutions to improve their way of working.

In a retrospective, a team reflects on their way of working. There are a lot of different techniques that can be used to do retrospectives, varying from asking questions with post-its to gather and organize the answers, building a timeline, root cause analysis to gaming (see Getting Business Value out of Agile Retrospectives which describes many of them that I have used in retrospectives). Depending on the situation at hand and what the team would be looking for, I usually pick a technique that would be suitable.

A technique that I use often is to ask “the four key questions”:

• What did we do well, that if we don’t discuss we might forget?
• What did we learn?
• What should we do differently next time?
• What still puzzles us?

Another failure (although I see this as a very positive experience overall as written above) was that I moved from the Netherlands too quickly. I had set up Bridge in 2006 and in 2008 I thought I had it all figured out for our Dutch office. We had two well performing sales guys and two project managers, we had been growing steadily for three years and we had just started our Indian office. So I appointed somebody as ‘director’ for Bridge Holland and left for India with my family. My plan was to build and grow our Indian company and then move on. But I had just landed in India when trouble started. First of all, recession started, which didn’t help us. We hired the wrong project manager (he was doing other stuff than what we paid him for to say the least), lost a big account, drove one of our account managers mad along the way (which resulted in his departure few months later) and started losing more clients in the spring of 2009 because of the financial crisis. So one year later, back I was in Holland. And it took me quite some time to rebuild what was destroyed. But ok, I had a great time in India!

I learned quite some lessons from this experience:

1. Don’t promote your best sales guy to sales manager

My company was growing steadily in the first few years and all seemed to flourish. I had a sales guy who was good at selling and brought us new clients. He was also social and everybody liked him. So I thought he’d lead the team we already had and would grow the company. It didn’t work out. I learned that in the future if somebody is good at selling, I will let him do that more and more instead of changing his responsibilities. Managing people is not the same as selling.

2. A company is nothing without the right people in the right seats

This point is related to the previous one: by changing the roles in the team, everything can change. We had a strong team that performed very well. The company was growing. So I assumed that the company would simply continue to grow because it was in the veins of the company. But that didn’t work out. I moved people around and the team dynamics changed, which resulted in our best sales guy resigning, a junior sales guy not performing at all and the project manager not managing projects but doing other things. Now I focus completely on getting the right people in the right seats and I know that only if all is in place, the company can grow. I learned the same thing in India, where it took me quite some time but once I had the right managers in place, the company started flourishing.

3. You need clear priorities and a meeting rhythm

I believed that I could focus all my attention on our Indian office and that’s what I did. And by doing that, I stopped putting the energy into my Dutch company as I had done the years before. I see this like growing flowers now: when you stop watering, they die. If you put in energy and water, they grow.

The challenge in my particular environment is that I have one company with several offices, which are in turn actually individual companies. So all of them need attention. But how to achieve this? For me, after my above experience, I learned that I needed more intense communication with all my people in all offices plus a structure to align strategy and priorities. We implementedthe Rockefeller habits from Verne Harnish. We invested substantial time in creating a one page strategic plan and started a rhythm of yearly, quarterly, weekly and daily meetings. All supported by google docs and communication through Skype. Since then, things started turning around because we were in daily contact whereas before we’d sometimes not speak to each other for weeks. Everybody knows what we’re going to achieve in the quarter and each person has an individual plan that we can keep each other accountable for.

The thing I disliked was having to go through so many mistakes. The first years, I was in the dark as to what one needs to do in order to cooperate with someone in India or Eastern Europe. I made all the mistakes you can imagine: hire the wrong people, work without any process, not using any online project management tools, communicating through chat only, work with suppliers that were not trustworthy, get stuck in the middle between client and supplier, not being able to deliver a project to a customer. And then another bucket of mistakes opening an office in India without any prior experience or Indian contacts.

> Hiring the wrong people
Although it seems easy to hire good programmers, because you can objectively judge the quality of ones code and you can reasonably judge the analytical skills, it’s less easy in reality. For having good remote collaboration, technological or analytical skills are only part of the equation. Communication is the most crucial aspect and it’s important to recruit for that skill. I also learned that hiring for values is crucial. Two of our core values that have the biggest impact on the success of our intimate work with customers are ‘openness’ and ‘responsibility’. I have dedicated another article to these too earlier. 

> Work without any process
The human spirit is to ‘just get going’. We find a good remote programmer or team and send requirements and expect it to work out just like that. I have learned that it’s crucial when you work across distance, cultures and language to have a common understanding of ‘how you are going to work’. If you don’t think about this upfront and people just do what they are used to, unless they by accident build the right routines, you’ll build the wrong ones and your offshore project will fail. 

> Not using any online project management tools
Technological advancements have helped a lot here, most people use tools like Jira, pivotaltracker, github and bitbucket, but 7-8 years back most remote work was just started by email and skype. If you don’t create an overview from the beginning using some online tool that tracks communication, status, bugs, questions, etc; your project will over time derail. 

> Communicating through chat only
The striking thing is that this can absolutely work, we have several clients that work only through chat and are satisfied. But what you miss is the personal relationship and the verbal communication. It also takes more time than talking. It’s safe to be behind the pc, certainly for remote programmers. But it’s also important to build that relationship and to work efficiently. Scrum is one of the instruments that helps remote work most and scrum goes with talking and video, not chat. 

> Work with suppliers that were not trustworthy
When I started Bridge I had only suppliers to work with. The ones I worked with soon appeared to be having too little programmers to process the work. So you branch out to other partners. It is hard to find the right partner and it takes time. But I have learned that you should take the time. I have also learned that for us it works better to have our own people, because we can decide whom we hire (on skills and knowledge, but also on values), how they work, how we build a team spirit, how we create some comfort and happiness among our team. I wrote an article last year about this topic. 

> Get stuck in the middle between client and supplier
Here I also learned an important lesson: for offshore cooperations to be successful, there should be as few managers in between the person asking to create a software application and the person building it. We used to have projects in which an end client wanted a webshop, hired a publishing agency for this, who hired a web agency, who hired us and we hired a nearshore team. In each company there was a project manager involved, which means at least 5 project managers. If one is sleeping, the project fails. So the best version is the end customer talking to the programmer and if he doesn’t possess the skills for that, he can hire a web agency who talks to the remote programmer. A side effect is that you save some extra costs along the way!

To illustrate the point, I will share an example. In one of our projects, an Indian programmer cooperates with a Dutch software development team. The scrum master is in the Netherlands and the product owner as well. The team uses two weekly sprints and decides on the user stories to be completed in the sprint planning meeting preceding the sprint (they use planning poker as well). 

The programmer in India commits to a certain sprint. His mindset is on delivering all user stories from that sprint within the given sprint. This happens often in projects that I am involved with; somehow developers keep the mindset of having to make a deadline, but scrum declares a shippable delivery by the end of the sprint more important than finishing every user story in the sprint. Because the developer (in this case working on his own remotely) commits to the sprint, he could as well move some of the user stories to the next sprint or the product backlog. But he is keen on finishing all. The result last week was that the user stories were finished but not at the quality level expected by the customer.

From the programmer’s perspective, he has been working very hard to show the customer that he can achieve results. But in the end he gets a customer that is not fully satisfied. 

In another project, a related thing happened. The programmer wanted to get the work done within the sprint. Because of time pressure, she chose to code the solution according to her own insight. The customer didn’t understand why she chose this solution. Had the scrum master done it himself, he told me, he would at first have spent more time understanding the product and the business she was working on (it is a recently started project so the developer does not have all the system and domain knowledge yet). On top of that he would have spent more time researching on the Internet for re usable code or a useful framework (and he added that most Dutch programmers would have done this as well). But our (Indian) programmer didn’t do that. 

What causes these issues to appear in cross cultural cooperations? (I have used two examples from India but I could as well describe one from Ukraine). 

I believe the root is in the mindset of the programmers. They see themselves as ‘coders’ and pride themselves in getting work done. Because of this mindset, they feel that they cannot spend time on researching, on spending time using Google to see how others solved similar issues. Because they have work to do, they don’t invest their time in diving deeper into the product or domain they are working on. They want to get clear tasks and get going with the coding. I believe that in India, the system stimulates this too. Most companies operate in strong hierarchy that is unknown to Europeans. There is an account manager responsible for client relations, a project manager for the overall project planning and communication, a team lead that distributes the work to the developers and then we have a programmer without big responsibilities other than producing code. On top of this, the tester will test the code by the way. 

Most European companies have the opposite mindset, they prefer quality over speed, they prefer a programmer telling them he can’t finish a user story and proposes to move that to the next sprint because he needs more time to research and test another user story. 

I see a few practical ways to change such issues from happening.

1. The first is to consistently stimulate the developer to invest time on research, to remind him consistently that quality is more important than speed. This will have a long term beneficial impact.

2. Plan for research, testing, domain investigation within the sprint. Create a separate task for this, assign a certain amount of hours to the task, so the developer knows it is ok and expected to do research, to test work very well before committing code. 

3. Have a clear definition of done (so the developer will always know what is expected of him) and add acceptance criteria to the user stories. 

4. Take enough time in sprint planning sessions to discuss solutions, before the developer starts the coding. Stimulate the developer to explain the proposed solution, estimate the workload and reach agreement on that solution. If he doesn’t know yet, add research time to the user story and let him describe the solution to you during the sprint before implementing. 

5. Create clarity on the hierarchy within the scrum team. Developers, especially in India, often see the scrum master (especially if he is from another country and working in the customers company) as a superior. They have learned that it is not ok to correct a superior in general, so they might hold back in sharing solutions with you and asking questions. They assume the superior knows best and will prescribe what to do. Keep repeating that the roles are all on the same level and reward ideas, suggestions and own initiative.

The typical situation in smaller teams (especially for companies that recently started with offshoring, they typically start with few developers) is to have the product    owner and scrum master in one location and the developers in another location.In some cases there might be even more locations even in smaller teams, for example a designer working from home, the scrum master and html coder in one office and the coders in another country. 

In the situation sketched, usually the product owner and scrum master do sprint pre planning meetings, either formal or scattered throughout the week. They add stories to the backlog in an online tool and have extensive discussions about the content of each story and maybe even describe tasks and subtasks. The sprint planning is then organized via Skype with the scrum master and the developers remotely. 

The challenges that arise in this case:

- The developers miss all interaction with the product owner. For the scrum master, things may already be clear but developers get second hand information and miss the power of discussing each user story with the product owner.

- You risk creating mini- waterfall projects in which all information is gathered by the scrum master (who basically becomes the project manager), who described the requirements and assigns them to the developers. This misses one of the main points of scrum which is interaction.

- Because the scrum master has clarity about what each story is about, he will make assumptions that he may not convey to the remote team. The remote team, especially when they are from another culture, may not be asking enough to get the same clarity and hence start development with incomplete information.

To avoid communication problems, some solutions can be:

- Organize the sprint planning with the whole team in one conference call and include the product owner.

- Create a bigger team and have the scrum master on the same location as the developers. This gives the remote team much more responsibility and ownership of what they are making.

- Limit the sprint preplanning where only scrum master and product owner participate, to describing user stories only on a high level. Let the scrum master fill all the details in the sprint planning with the developers.

 Maybe you have some additional solutions from your own experience? 

I have spent a good number of years encouraging both small and large business owners to take advantage of outsourcing, by hiring outsourced employees to run certain business functions. I have even written a book on the subject called “Outsource This”. There are so many advantages of hiring an outsourced employee, some of these advantages are: 

• Outsourced employees will only charge for the specific time that they work for you. For example, at 123 Employee, there are three packages you can choose from; this will depend on the number of hours that your outsourced employee puts in.
• You do not have to shell out money in order to purchase equipment for your outsourced employee. He or she will use their own equipment – you only get to pay a small onetime set up fee for your outsourced employees. This will include everything such as the office, chair, desk, internet connection, unlimited outbound and inbound dialing and local telephone number in your area of choice – this way, you will be able to communicate constantly with your outsourced employee. You will not be charged taxes, or additional fees and you are not obligated to sign a long-term contact. You will also not have to bother about going through the process of setting up an office, or purchasing office stationery and other office resources for your offshore outsourced employee. 
• You will also not have to put aside a huge chunk of money to pay worker’s comp, employment insurance, sick pay, 401(k)’s and other retirement plans. You also do not have to put up with well constructed lies that many employees make up in order to get a break from work after a previous night of heavy drinking and a morning hangover. Why should you pay anyone to slack off?! 
• This is my favourite; you do not have to shell out any money for agency fees.  It is no secret that temping agencies charge agency fees in order to work with them.
• One other advantage that you get to enjoy with your outsourced employee is time zone benefits; while you are asleep, your outsourced employee is getting things done.
• You also do not have to worry about spending money in order to give your outsourced employee specialized training; this is because he or she has already received quality training. 

Here are tasks that your outsourced employees can perform:

1. Marketing
2. Research
3. Medical Billing
4. Virtual Assistant
5. Data Processing
6. Recruitment Process
7. E-commerce
8. Real Estate

When you are working with an outsourcing service provider, you can count on getting absolute value for your money.

To learn more about outsourcing and get your free copy of my book, ‘Outsource This!’ visit http://www.123Employee.com.

Daven Michaels is an award-winning outsourcer and author of the book, ‘Outsource This!’ Daven has been honored more than any other individual or outsourcing organization. You can get more information on outsourcing by visiting http://www.123Employee.com

In this article, I would like to share (a short version of) my personal story with you. I have done a short interview with myself:

What drew me to this market?

An odd combination of events. Short after the millennium I was working in a publishing company in Amsterdam. They published city maps, sponsored by advertisers from each city. The interesting thing about this organization was the division between their sales office, which was in Amsterdam and their studio, which was in Breda (some 100 km away). The sales office would gather all the materials for the ads from customers (this was the CD ROM pre-fast internet era) and send it by post to Breda. The designers in Breda would create the ad and send a print proof back to Amsterdam. Amsterdam got it confirmed (or gathered changes) and so the process went. So I wondered, if this company makes a process to create designs remotely, why wouldn’t it be possible to do this in another country where everything is cheaper? 

Around the year 2000, the IT market hit an all time high, companies couldn’t find programmers in their own country and started searching elsewhere. India started booming as its government had invested in educating loads of engineers since the 90s. 

So I left the company and travelled through India for 3 months. And that’s when I decided that I had to found an outsourcing company. The whole country spoke and dreamed about IT and still does. IT is India’s way to become a world power and move staggering amounts of people out of poverty. And there is an abundance of smart, friendly and hard working talent. I wanted to become part of this movement, which in my view contributes to a better balance in the world as it creates jobs in developing countries while bringing growth and profit to both developed and developing countries. 

What do you like about it? 

First of all, the fact that I could build an interesting business within the offshoring industry. I love working with and meeting up with people from other cultures. I find it incredibly challenging to find ways for people to cooperate remotely: in each cooperation we set up with a client, we have to find the way for them to work with the programmers we hired for them. It is satisfying to make that work out, to see that the cooperation between someone in Western Europe with someone in Eastern Europe or India produces positive experiences. 

I also find it inspiring to build our company culture across borders. I had initially built a company that worked as an intermediary between customer and foreign supplier. But that gave me no influence on what was going on inside the ‘black box’ of the supplier. Since 2008 we started setting up our own offices, first in Ukraine, then in India. In our own offices, we’re able to decide who joins us and to deliberately build a culture that stimulates behavior needed to succeed in cross-border cooperation’s. 

 What do you dislike?

 The thing I disliked was having to go through so many mistakes. The first years, I was in the dark as to what one needs to do in order to cooperate with someone in India or Eastern Europe. I made all the mistakes you can imagine: hire the wrong people, work without any process, not using any online project management tools, communicating through chat only, work with suppliers that were not trustworthy, get stuck in the middle between client and supplier, not being able to deliver a project to a customer. And then another bucket of mistakes opening an office in India without any prior experience or Indian contacts.

If somebody had told me upfront that I would have to learn 5 years to figure out a business model that will work and make people happy, it’s likely that I would have chosen another venture. But now it works, and then again, it is better not knowing what lies in front of a new venture as otherwise you wouldn’t start. 

 What are your greatest achievements and failures? 

 The biggest achievement is that I have built a company with great people, spread out over many countries, that knows how to make remote collaboration work. I had set out to build an outsourcing company and through trial and error, we have developed a formula that works.

Specifically I am proud of our office in India, where about 30 people work together in a culture that feels like a family. Every time I speak to my colleagues, they tell me that our culture is different from any other company in Kerala, that the company feels like a second home. I didn’t know anything about setting up a business in India, started completely from scratch (took my back and a friend to Cochin and we rented an office and off it went) and went through many hardships. And it worked out. 

A more personal achievement was living in India with my wife and 8 months old twins. This gave our family a fantastic experience, made me understand Indian culture on a deeper level and enabled us to lay a strong foundation for the company. 

And then failures. First of all, there were many failures on the customer side. I didn’t know a thing about managing remote cooperation’s when I set out with Bridge. So I had to screw up a lot of projects to learn what I should and shouldn’t do. 

Another failure (although I see this as a very positive experience overall as written above) was that I moved from the Netherlands too quickly. I had set up Bridge in 2006 and in 2008 I thought I had it all figured out for our Dutch office. We had two well performing sales guys and two project managers, we had been growing steadily for three years and we had just started our Indian office. So I appointed somebody as ‘director’ for Bridge Holland and left for India with my family. My plan was to build and grow our Indian company and then move on. But I had just landed in India when trouble started. First of all, recession started, which didn’t help us. We hired the wrong project manager (he was doing other stuff than what we paid him for to say the least), lost a big account, drove one of our account managers mad along the way (which resulted in his departure few months later) and started losing more clients in the spring of 2009 because of the financial crisis. So one year later, back I was in Holland. And it took me quite some time to rebuild what was destroyed. But ok, I had a great time in India!

 How would you advice others on offshoring?

 First of all, I sincerely believe that unless you are building a company similar to mine, it is not a good idea to setup your own team in another country. Of course you may be lucky, but I am confident that you’ll face many of the hardships described above. Although I wouldn’t want to have missed them, I think it doesn’t make economic sense for an SME to invest the time and money I did in a captive center. 

The most crucial aspect is getting the right people in your newly found company. And you’ll choose the wrong ones invariably (again unless you are lucky), because you don’t know what to pay attention to in another culture. On top of that, you’ll have to learn how to work with remote teams. 

I believe it is crucial for European companies to engage in offshoring, because there is no denying that it’s hard to find talented people. And it will go worse now the population gets grey. The safest course of action is to work with a company that knows how to get the right people, that already has a set up and above all, can help you in managing your remote team. If your dream is to own a foreign subsidairy, you could start with a supplier and agree to establish a joint venture that takes over the team after x years. 

On a more general level, I recommend everyone to start working with remote developers. It enriches your life, you get to see more than your home country, you learn a lot, better the world and have fun along the way!

It would be great if some readers could share some personal anecdotes as answers to the questions above! 

As most of you are likely busy planning and strategizing for 2013, I want to plant an idea. When you think about offshoring, your first idea will likely be ‘ah, low costs’. But is this really the case and is it the most important reason for putting offshoring or nearshoring on your agenda for 2013?

Three weeks back I visited our Indian office together with one of our customers. We had a great time and thanks to the flights and shared hotel, we discussed a lot. One of the main things he mentioned is that actually, offshoring is not about costs. The thing he couldn’t see clearly before they started working with us (he said he choose us because we have a good story J), is that the benefits for him are not (only) costs. Although it is cheaper to hire someone from India, there are three things that strike him.

First of all, he gets highly talented programmers, which are hard to come across in the Netherlands. He had plenty of time to speak with Hari, his main php programmer and realized that he’s a smart guy. Sometimes, doing all the works through skype on a distance, makes us overlook this fact. Communication barriers block us from seeing the real value in the person, so meeting up in personal is essential for longer term success.

Secondly, he’s got a flexibility that he’d never get with employees locally. Now this flexibility may differ per supplier, but in general it is much easier to stop a contract with our offshore developer than it is with a local employee. Connected to this is the third aspect, scalability. This client is launching a new software product. Investment in the beginning has to be modest, but once it starts picking up, he needs more developers to scale. In India it’s a lot easier to find developers than in the Netherlands, so we could ramp up the team within short notice.

Those are the business motives. The last motive that I think is sometimes overlooked: it’s fun. Most people like travelling, meeting people from other countries, exploring new territories. We do this every year going on vacations. So why not combine business with the nicer aspects of life? The time I spent with my customer in India was great as if I went on holidays with a friend. They also enjoyed India and were inspired by the possibilities and movement of India.

I would suggest you put offshoring on your agenda for 2013 and give it a try! Start with one or two programmers that you select yourself, get experience in building the right global communication routines and extend the team once you see that it works for you. 

]]> http://bridge-outsourcing.com/bridge-outsourcing/how-will-you-combine-fun-with-business-benefits-in-2013/feed 0 http://bridge-outsourcing.com/bridge-outsourcing/offshore-outsourcing-services-%e2%80%93-is-offshore-outsourcing-beneficial-to-small-business http://bridge-outsourcing.com/bridge-outsourcing/offshore-outsourcing-services-%e2%80%93-is-offshore-outsourcing-beneficial-to-small-business#comments Mon, 24 Dec 2012 09:30:48 +0000 Daven Michaels http://bridge-outsourcing.com/?p=4906 Continue reading →]]>

Some small business owners wrongly assume that offshore outsourcing services are for the fortune 500 companies alone. Also, the mere thought of entrusting their business functions to an offshore vendor disturbs small business owners. Yet, small businesses are one of the greatest beneficiaries of outsourcing, especially when it is done for the right reasons and in the right way.

Typically, the small business owners handle virtually every aspect of their business alone. They feel more comfortable to do so, having the notion that nothing would go wrong, when they take complete charge of their business functions.

On the contrary, a recent report from US Business Association reveals that most tasks carried out by small business owners (spending quality time to do so) are not usually profit-oriented.

While a small business owner is considering fund-intensity as the requirement for offshore outsourcing services, it is indeed cost-effective to hire an offshore vendor for business functions, especially the functions that are complex in nature. Then, you can refocus on the core activities of your small business.

When Is it Necessary for a Small Business to Outsource?

As a small business owner, your business will keep growing and would thrive to a point when you will suddenly notice how difficult it has become to handle the tasks alone. Topmost in the list of such tasks is customer service. If your business has reached that growth level, it is the right time to seek for external help. Compared to the cost of getting the external help in-country, it is usually cheaper to outsource tasks such as customer service or help desk to an offshore contractor. Thanks to the internet, in a couple of minutes, you can scan through the profiles of top-notch offshore providers and make the perfect selection after further investigations and research.

To clear the doubt that may be in your heart regarding the cost of contracting offshore outsourcing services versus in-country provider, you can interview 5 people in-country and 5 people offshore to compare wages. Subsequently, you can settle for the option that promises the best cost advantage. Going by global analysis, offshore outsourcing option will always win the contest.

Here are some costs you will by-pass by hiring an offshore employee;

• Monthly wages plus government-imposed health/welfare benefits
• Office equipment costs
• Utilities
• Cost of training and re-training staff
• Employment insurance
• …and others

Obviously, a small business is not capable of footing the recurrent bills associated with in-house or in-country staffing. It is far way cheaper to embark on offshore outsourcing services. It helps to maximize cost savings advantage, hence increasing profits significantly. However, profound selection process is necessary for successful outcome with outsource offshoring. We’ve written a couple of useful guides on how to select the right offshore partner.

In my work as an agile and lean consultant, there’s sometimes a lot of discussion about “processes”. People I work with use different definitions of processes. Agile teams sometimes resist to processes, when they refer to the agile manifesto that says “Individuals and interactions over processes and tools”. So the question: What are agile processes?

My definition of a process is “the way we do things around here”. It can be documented in a process description or quality system. But it can also be something that professionals do, simply because they have had similar training. What they have learned from experience, by frequently evaluating they way they work and look for improvements. A team may agree to do things in a certain way, based upon shared beliefs. So in my opinion a process is what people actually do. That can differ from what they say they do, or from what is documented. For me it is the actual behavior that counts!

It’s not the process that changes, it’s the people

Why do I use the definition “the way we do things around here”? The way to change results of an organization is by changing the behavior of the professionals that work there. Writing new process documents or changing an existing one doesn’t automatically result in change: a document is not a process. It’s what people do that counts.

Calling it “the way we do things around here” doesn’t mean that things should stay the same. “This is the way we do it” is not a process, it’s a denial, an excuse for not willing to change. If the way things are done isn’t effective, if it causes software to be delivered late, with insufficient quality, then things must change. My opinion is that change always starts from how people are working right now, not from how it is written down in a document.

Agile processes

Do you have processes in agile? Of course! As an agile team you agreed to work in a certain way, which is your process. Every sprint you discuss how you will deliver the user stories, which is also a process step. And you continuously improve the way of working with retrospectives. Most agile teams use a Definition of Done, which I consider to be a process definition, written by the team itself. Agile teams have shown to be a great way to deliver high quality software products. So yes, there are processes in agile, and agile actually has some process management build in. Also the newest CMMI V1.3 recognizes Agile, and Agile processes, so you can use a combination of CMMI and Agile to improve your business. You can even improve in an agile way, to continuously increase the value that your company delivers to your customers.

I’d like to hear from you: What is your definition of an “agile process”? How do you use it?

More information

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

 Uncovering Better Ways to do Process Improvement
 Becoming Agile and Lean
 Agile Project Management
 Golden Rules for Agile Process Improvement

I started in the offshoring/nearshoring/outsourcing market in 2005 and in that year, I already heard people share negative stories about offshoring. Today, in 2012, this is still the case, maybe even more, as more people have experience. It surprises me that there are so many cases where people get a negative experience.

But at the same time, the size of the markets grows like a rocket and companies offering offshoring and outsourcing become massive. Infosys started little more than 20 years back and has over a 100.000 people working for customers all over the world.
In Eastern Europe the same happens in the last decade, some companies grow to several thousand people serving Western European customers. So there are also many positive experiences, otherwise outsourcing would not exist. What is the underlying reason? 

I believe there are several reasons:

1. Offshoring is a relatively new phenomenon. So there are many people without experience in managing remote people, who decide to outsource projects. And there are many providers who don’t have a clue how to manage remote relations. And software projects regularly have results that were different from expectations. Adding language distance and cultural distance to this doesn’t help. And things need to go wrong before they start going right.

2. There are low quality offshore suppliers. The IT industry in many countries has grown rapidly. This attracts all sorts of people who want to earn a buck, providing services. Not all of them can be good at what they do. 

3. Often companies choose the wrong model. The traditional way of developing software in another country is working project based, often with more or less fixed prices and a waterfall-approach. Requirements are extensively documented, sent to the ‘other side’, the ‘other side’ makes a planning and then we start. Four weeks down the road there is a milestone and that’s the next moment we have contact. No result. At least not what we expected. Let’s try again? 

4. It is not easy to work remotely. You need to get used to it, you need to choose the right tools to support your remote work, you need a good way to communicate with each other and many more factors (I have written many articles on what is required to make remote work smooth). If you expect to get the right way of working within one project or within a few weeks, you might get a negative experience.

The question is, what do we need for an industry to improve upon the overall customer experience in outsourcing and offshoring? 

My own insight, linked to each of the above points:

A. We need time and learning. The more experience one gets in managing remote team members, the better one gets at it. It helps to involve people who know how it works, who can help in choosing the right tools, the right way of communicating and help to overcome cultural differences. 

B.  Customers of course need to perform a good qualification when selecting a provider. We may need a quality label for offshore providers.

C. My experience is that the best model to make remote work is to have dedicated team members. Of course this is preaching for my own model, but I have tried and seen all other models and having people who are part of your team and feel connected and responsible, simply works better. You want to have a choice in the people that work for you and you want them to work hard to make your projects a success. And this works better if human beings have a common ground and feel connected to the same goal. 

The agile or scrum based methods helps the industry too. The combination of having a dedicated team and a flexible model to build your projects, works…. if you have the right people, you know how to streamline the communication and you choose the right tools. 

I would appreciate other insights. What do you think cause + solve the negative experiences and messaging? 

One thing he mentioned made me think. He told me that in his company, they want to hire the people that live and breath technology, people who are always playing with their pc, in the evenings, weekends, always. And always try to learn new technologies, because they have an in-built curiosity for new technology. With such people on board, you will build great products. 

Then we arrived at discussing India. I told him that in India, the whole country breathes IT. IT is believed to be the main industry to put India on the map in the decades to come. This leads families to put all their savings apart just to get their children on one of the IT universities. The Indian government has stimulated this since the 90′s and this results in the massive amounts of IT specialists that India produces every year. Now the question is: if your family motivates you to start working as a programmer to bring prosperity to the family, will you become the real technology enthusiast most companies would love to have? 

In the Netherlands, there are only about 2000 IT graduates per year, because most people don’t choose a technnical path in their lives. But those people must be intrinsically motivated to choose that path. The same is true for many countries in the rest of Western Europe and also Eastern Europe. The former Soviet Union stimulated people to go for a technological education but for different motives. The past decade, the IT industries in Eastern Europe have grown substantially following the success of outsourcing to India. The role of government in for example Ukraine, is less articulate in motivating people to follow a technical education as far as I know. I do not know to what extent Eastern European families put all their savings into the IT education of their children, but from what I know, this is less so than in India. 

Nevertheless, there is an abundance in very smart and motivated IT people in India. And the same for Eastern Europe, where you could also find people that are not as motivated and ‘IT-fanatical’ as you would hope.

Could there be a difference in the average quality of the programmers in one country, caused by the reasons programmers become programmers? 

It would be interesting to receive some perspectives on this question both from people in India and in Europe.

]]> http://bridge-outsourcing.com/bridge-outsourcing/what-is-the-difference-between-an-indian-and-eastern-european-programmer/feed 3 http://bridge-outsourcing.com/bridge-outsourcing/openness-and-trust-in-offshore-relationships http://bridge-outsourcing.com/bridge-outsourcing/openness-and-trust-in-offshore-relationships#comments Tue, 16 Oct 2012 04:41:12 +0000 Hugo Messer http://bridge-outsourcing.com/?p=4760 I am reading a book called ’100% succesvolle IT-projecten’, written by Klaas Jung and Gerard van de Looi. They write about the key success factors in IT projects. One of the chapters that stand out for me is about relationships and openness. They write: ‘The more you open up for the other person, the bigger the chances that you receive trust. The … Continue reading →]]>

I am reading a book called ’100% succesvolle IT-projecten’, written by Klaas Jung and Gerard van de Looi. They write about the key success factors in IT projects. One of the chapters that stand out for me is about relationships and openness. They write:

‘The more you open up for the other person, the bigger the chances that you receive trust. The contradiction is that people often get more closed, because they are afraid to be punished for being open. In an atmosphere of mutual trust, you can be open, you can discuss problems and you solve problems quickly together. But when we are not open and keep problems for ourselves, the other starts mistrusting us. In turn, the other will also react more closed and we create distance.’ 

In relationships that cross borders, cultures and language, I believe the challenge for making IT projects work well, depends on being open even more than in local projects. Openness differs between cultures. Unless we learn how open another person from another culture is and expects us to be, communication will get blocked and trust is low. The goal in an offshore relationship is to work together comfortably and as we already have distance in culture, language and geography, we need to decrease the personal distance. 

The authors describe what factors contribute to an equal relationship on which trust and communication can be built. 

1. Respect: If one person has less respect for the other person, the relationship will grow distant. If one person will be obedient to the other person, this can lead to suppression. This is often based on the idea of the customer ‘we pay the invoices so you have to do as we say’. If both sides have respect for each other, the relationship will be equal and will work well on longer term. The perception of respect varies strongly across cultures, so we need to explore how the other person perceives us and respect for other people in general. 

2. Forgiveness: In all projects, people make mistakes. We need to learn from mistakes to get better. If one person doesn’t forgive the other for his mistakes, the relationship will break eventually. Culture plays a big role here. In cultures where hierarchy is important, the relationship between boss and employee or customer and supplier tends to be different from cultures with less power-distance. 

3. Maintenance: In all human relationships, we need to invest energy in keeping the relationship healthy. In an IT project, it is important to invest in the relationship not only in the offer-phase, but during the whole project. With people being remote from each other, the challenge here is even bigger as we have less frequent (face to face) encounters. 

4. Fear of conflicts: In an equal relationship, all topics (positive and negative) can be openly discussed. People can then openly share problems, without being afraid of a conflict. People from different cultures tend to have a different attitude towards conflict. In order to make the relationship strong, we need to be open and we need to explore from both ‘sides’ to what degree we can or cannot create conflict with the other person. 

When I decided that I’m really going to India for my Internship in Bridge IT staffing company, I had no idea what to expect. For me India was an unexplored country but with so much to explore therefore I decided not to build any expectation but to take everything as it comes. In the beginning of September I was leaving my family and everything that made me feel safe at home in Sweden to move about 7300 kilometres southeast to discover a new country, new culture and new people. 

Namaste India..

In a country where you don’t look like the locals, and you don’t speak the same language or share the same culture as them it’s easy to feel like you don’t fit in. After my first month in India and in Bridge I can honestly say, that thought have never crossed my mind. One of the first thing I got told when I came to Bridge was; you didn’t leave a family behind, you came to visit and get to know a new one. I’m so fortuned to say that there is a truth in every single word. The people at Bridge really are like a family and they are open and friendly to let others in to be a part of the Bridge family. 

If I would need to compare or only describe the differences between India, or at least Kochi, with Sweden I would say that it’s not just the culture that is different; it’s everything from the palm trees, the houses, the shops, the clothes, the food and the animal walking around loose in a city with the highest population density in Kerala.I would have to say that it’s different but awesome. It has now become my regular answer because believe me, I get that question a lot 

My first day at Bridge…. 

My first day at Bridge, I have to admit, was a bit overwhelming. I meet all my new colleagues, I got to see the office spaces and how they worked and I had my first real local Indian lunch that I, of course, ate with my hands. The atmosphere at the office was so relaxed but still professional. Also everyone at Bridge are so open to get to know more about my culture and where I’m from just like I want to learn and be apart of the Indian culture. They make the work and the cultural different seem so small and easy. Just by stepping in to the office you can feel that one of the most important things for Bridge is the people. The people is as important internally in the company as it is to provide the customers with the right people that would fit in to their organisation, working process and project. If the people don’t work together or are completely unsatisfied then they can’t do a good job. In the video below you will find some of my favourite photos in India and Bridge which I would love to share. 

 The world is getting smaller and smaller. The boarders between countries are getting weaker. The culture integration between people from different countries is becoming more frequent and more necessary.My journey in India and with Bridge has just begun and there are so many things about India and Bridge to learn and see. I know already that this year will make me grow as a person both professional and personally and it will teach me to look at things from different angles and in a different way which will help me to evolve.

Some years ago the Software Engineering Institute (SEI) published the technical report CMMI or Agile: Why Not Embrace Both, to describe that CMMI and agile can co-exist. I was surprised that such a report was needed. All the projects that I have managed or worked in used techniques that are now considered agile, like iterative development, frequent feedback from customers, time boxing, pair programming, and test driven design. And most of the organizations that I worked with used the CMM(I) to assess their processes, and improve the way they developed and managed software. I have also done process improvement projects in an agile way. Agile and CMMI always somehow support and even strengthen each other.

Of course there were good reasons why the SEI published the report. They saw that people who were using the CMMI, opposed against Agile. They opposed that Agile is not a managed process, and could be used as an excuse for not writing any documents. On the other hand there were also Agile evangelists who considered the CMMI to be too big and unworkable, and didn’t see any focus on people and collaboration in the CMMI. The technical report makes clear how Agile and CMMI support each other. The SEI has also included Agile support in CMMI V1.3 to make again clear that Agile and CMMI can co-exist. My opinion is that Agile CMMI is a strong combination, to deliver valuable software in a managed way. Let’s see how deploying the CMMI version 1.3 delivers value for Agile organizations. 

CMMI and Agile complement each other

I think that a lot of the opposition was mainly due to people that didn’t understand both the CMMI and Agile. There are subjects where CMMI and agile can be interpreted in conflicting ways. Like the emphasis in the CMMI on plans, where agile puts more value in responding to change, and how agile values individuals and interactions over processes and tools, where the CMMI focuses more on processes.  But I have always considered agile and CMMI to be complementary, and luckily I’m not alone in this. I see much (practical!) support in a book from Barry Boehm and Richard Turner, Balancing Agility and Discipline, a Guide for the Perplexed. This book helps you understanding how much planning is needed (yes planning, not plans as Eisenhower taught us!), and how the disciplined way of working that agile contains makes it a very effective process.

In CMMI V1.3, agile has been included with interpretation guidelines and by adding notes to the applicable process areas in the introduction of the process area and on how to interpret agile practices. This way of including agile information is very helpful, you find information at the spot, condensed and to the point. It also make the CMMI easier to understand when you are working in an agile organization. And in case you didn’t know it, there is also a Dutch version of the CMMI V1.3, with agile support, available.

Agile Techniques and CMMI practices

The CMMI uses practices to give examples of activities that can be used to reach the process goals. CMMI version 1.3 has been extended and now mentions agile techniques in several process areas. For example, the process area Process and Product Quality Assurance describes that retrospectives can be used to evaluate processes, and the process area Quantitative Project Management mentions Agile velocity as a project measurement.

Some agile techniques are not mentioned in the CMMI V1.3 practices. It doesn’t mention specific methods, like Scrum, XP or DSDM. It mentions some agile techniques, like user stories, backlogs, story cards, pair programming, frequent builds, retrospectives, but doesn’t mention others like planning poker, test driven development, burn down charts, etc. There is room for interpretation in the CMMI process areas, which in my opinion is both bad and good. Bad because not including certain agile term makes it more difficult to recognize and map agile practices to the process area. But the good thing is that the CMMI defines the “what”, and not the “how”, leaving room for organizations to deploy agile in such a way that they reach the business (and CMMI) goals.

Improve Continuously

CMMI uses two representations: staged and continuous. The staged representation is the most used representation, although the continuous representation is commonly perceived to be a more flexible option. Often, potential CMMI users do not select the continuous representation because they find it difficult to pick “the right set and order” of process areas for their situation. CMMI roadmaps, which are a goal-driven approach to selecting and deploying relevant process areas from the CMMI model, can provide guidance and focus for effective and continuous CMMI based improvement.

Similar to the CMMI, Agile also focuses on continuous improvement. The sprint review or demo provides feedback from the customers and stakeholders, and retrospectives help teams to reflect and improve. It’s not being, but becoming Agile and Lean that brings benefits. The journey, where you learn and improve continuously is more important then the destination. The concepts on how to do continuous improvement in Agile and the CMMI complement and strengthen each other.

How agile is the CMMI V1.3?

I find it a bit strange that agile has only been added to the CMMI Development model, and not to the CMMI for Services (except for Service System Development). In my opinion, services can (and probably should) also be developed and deployed in an agile way to ensure timely delivery and maximum benefit for the customers. I am sure that there are companies that have used agile to develop services (just like I have used agile to do process improvement). The CMMI for Acquisition contains agile information in several process areas to support acquiring from organizations that work agile, however I see very limited information on how to do the acquisition in an agile way. Also the agile interpretation guideline is missing in the CMMI for acquisition. But maybe that’s a step to far for now.

If you use the CMMI as an assessment model, then the many elaborations on agile will certainly help you to recognize an agile implementation of a process area. By adding agile information to the CMMI, CMMI assessors will have less questions about how to interpret the CMMI, and thus save time and money in an assessment. If you use the CMMI as an improvement model, then the agile additions are helpful but not sufficient to implement agile practices into an organization.

Learning from each other

The LinkedIn group Agile CMMI (over 12.000 members) is where professionals share their experience on CMMI in organizations that are (becoming) Agile. A great source of inspiration and solutions, I’m an active member of this group, and highly recommend it!

everal CMMI experts have published about the CMMI V1.3, including how to deploy it in Agile organizations. One available solution is to use the People-CMM to implement agile practices. There are also some Golden Rules for Process Improvement, that fit neatly with the Agile manifesto and practices.

Conclusion

CMMI and Agile support and strengthen each other, and CMMI V1.3 is a significant improvement for organizations that are using agile practices, and makes it much easier assess an agile organization. If you want to migrate to agile, the CMMI V1.3 is valuable as an improvement model, but you will probably need other supporting models for the implementation of agile. 

More information 

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

• Becoming Agile and Lean
• Golden Rules for Agile Process Improvement
• CMMI V1.3: Summing up
• Using Scrum for Process Improvement
• CMMI V1.3 Process Areas

Outsourcing is the process through which a company hires another company to provide labour or to play some function for them instead of using their own staff to carry out the function. Today, outsourcing is becoming the order of the day. Many companies are now outsourcing their businesses, due to the benefits that can be derived from it. Today, outsourcing has taken a new turn. It is no longer limited to businesses in the brick and mortar shops. Businesses in the internet and other computer-based systems known as e-commerce or e-comm in brief are now being outsourced.

A recent study shows that many e-businesses are hiring the services of an outsource company to help in the running of their e-commerce in order to enable them to cut costs. Most of the companies that are hiring the services of e-commerce outsourcing companies are small and medium e-businesses. There are a number of ways in which outsourcing companies can be of help to these e-businesses. E-commerce outsourcing companies can provide web design, development, management and operation services. They can also be hired to procure equipment to an online business. Promotion of a business and its products online can also be done by outsourcing companies.

The advantages that can be drawn from outsourcing are the reason why the practice of outsourcing is growing in popularity and spreading like wildfire. Indeed, there are a number of advantages that can be drawn from the practice.

E-commerce outsourcing is cost effective. The first reason why many businesses are entrusting the running of their businesses into the care of outsourcing companies is that it is cost effective to do so. The need to cut costs in the running of a business, especially in hiring workers, has brought about the existence of outsourcing companies. The outsourcing companies provide labour and other functions to companies at a cheaper price. Therefore, many e-commerce businesses outsource the running of their company, simply to save on labour and the operational cost of their business.

E-commerce outsourcing helps in the promotion of a business in the internet. The internet business is highly competitive. Every business wants to be visible on the search engines and this means occupying the prominent positions on the first page of the search engine. This requires a high level of expertise. The e-commerce outsourcing companies hire experts that are knowledgeable and skilful on how to popularize a business online.

 E-commerce outsourcing companies themselves are into competition with each other and so they will like to execute their functions with a high level of proficiency, so that they will get referrals and good reviews. Therefore, if the company that hires an e-commerce outsourcing company becomes successful or becomes visible on the search engines, definitely the magic power of words will bring other clients to that outsourcing company. In other words, a small or medium business will benefit from the expertise of the outsourcing company that it hires and this will surely help the business to generate reasonable traffic on the internet.

via,http://www.123employee.com/articles/ecommerceoutsourcingbenefits.html

To learn more about outsourcing and get your free copy of my book, ‘Outsource This!’ visithttp://www.123Employee.com.

In the Netherlands, home-working has been growing rapidly in the past years. Existing companies are stimulating people to work (partly) from home, creating flexible desks in their offices. Many people become freelancers and work where and when they want. And more work is moved offshore or nearshore. 

This trend is likely to continue and might even accelerate. The two main developments that will accelerate the speed:

1. People gain experience in how to manage people remotely (be it in their own country or somewhere else on the globe). Working together remotely requires different behavior, mainly because you don’t see each other face to face all the time. I have seen this development in our own company, where in the beginning we had our team in the Netherlands in one office and suppliers offshore/nearshore. Right now, we have 7 sales people working from 5 different countries as one team. And on top of the suppliers, we have 3 development offices in 3 countries. This requires a very specific behavior of people. 

2. Technological advancements. 6 years back there were almost no online project management tools. Today, there is abundant choice, both open source and paid. 6 years back, version control had just started. Today, we have github, which replaced svn, which replaced other systems that existed earlier. Version control gets integrated with project management tools so code is linked to specific tasks or functionalities. People invent new tools every day to facilitate remote working. Without the internet it was hardly possible to work remotely. Without skype, communication was very expensive. In 10 years we will have tools that will make us feel as if we are sitting next to eachother at the same desk (a solution already exists for this). 

The question I raised in the title is what work could be done remotely. What is the limit to the type of work that can be done by someone sitting on the other side of the planet? I believe that anything that can be done using a computer and a wire, can be eligible for remote work.

In the world is flat, Thomas Friedman describes some cases that seem futuristic, but might become reality on a big scale. There are fast food restaurants in the US that have a drive-in where you ring the bell, the order is taken by someone in India, entered into a system and within minutes, your order is made ready by the local US person and you take it with you. I also spoke to someone at Deloitte who told me that they are flying in many consultants from India to their customers in the US and Europe. And the research and reports that they make are also created in India on a large scale. And that’s just the beginning he told me. 

In our company, we also try to do as much of the work from our Indian office. Our bookkeeping, financial reporting, lead creation, social media marketing is all done from India. I write a blog article and Sini in India coordinates the translation, then posts the article, uses the content in our newsletter and spreads it in social media. Babitha creates our invoices with Twinfield, an online system (which didn’t exist few years back!), sends them to our clients and administers all reminders and payments. The only thing that we do locally is sales and personal support for our customers. 

Bridgys from 6 nationalities are connected with a clear communication process…. 

Dear Reader,What do you think?What is the limit?

1. Start with asking yourself why you want to offshore?

Do you see offshoring as a low-cost solution for a few projects that you have? Or is it part of your long term vision to grow your company? If you have a few projects that you want to do cheaply, you may want to find your supplier through a project website like elance or odesk. If you have a longer term vision, it makes more sense to search for the best matching company directly.

2. How do you plan to work: outsource projects or hire people?

The natural inclination of most people that start with outsourcing is to work on fixed price models. The perceived advantage is that your partner has the risk of delay or extra time spent. But in most cases, this fires back. The disadvantage is that you have to spend much time on the specification phase; plus you will get a lot of discussion about estimations and extra time spent.

The alternative is to hire people on a fixed monthly fee or on post-calculation. The advantage here is that you can influence who is working on your project and how they work. The disadvantage is that you will pay every hour spent (which is often also the case in the fixed price model although it looks like you don’t). 

If you know what model works for you, you can screen the suppliers based on that model. If you don’t know, I would recommend inviting two or three supplier for a (skype) meeting and listen to their story on the plus and down sides of their model. 

My personal experience is that long term results are only produced by going for a people-oriented model. You should be able to hand-pick the people that are working for you, you should have direct communication with them (if a supplier doesn’t allow this, you may also have another screening criteria). It should be your own team of people that are dedicated to making your company and project a success.  

If you decide to go for a supplier that gives you the opportunity to select your people, you could simply ask them to send you some candidates and have an interview of them. You can do this with a few suppliers and the one that provides you with the right people, you get involved with. 

3. How do you plan to communicate?

Many companies adapt (variants of) agile and scrum in their software development process. If you have such process, you will have a default way of communicating between your customers, your project managers and your programmers. You could map this communication process and search for a supplier that matches this process. 

Then ask the supplier ‘what is your communication process’? and see if this matches your vision of how communication is supposed to work. 

My personal experience has taught me that the most important part of offshore success (along with choosing the right people) is communication. Without going into the details, the basis for communication is having daily contact about your project with the offshore team + having weekly review-meetings in which you discuss whether the project and communication goes well or what can be improved. If a supplier doesn’t have any communication structure that looks like a daily/weekly rythm, I would take them off my list. 

4. Do you involve a local company or not?

You can use google to search for companies all over the world or in a specific technology or country. You can also involve a company that has a local presence in your country. There are many companies from India or Eastern Europe that opened offices in Western Europe. And there are companies that are originally from your country and opened offices offshore or nearshore. The advantage of a local company is that they have experience in the cultural difference, in remote communication, in offshore project management. They have gone through the pitfalls of offshoring and can help you to prevent them. 

My personal experience. When I started Bridge, I had no contacts, no experience. I randomly started searching for suppliers that could help me to setup my global IT staffing company. I have spent an incredible amount of time in searching for and working with nearshore and offshore suppliers. And the conclusion I made is that you have no influence on what they are doing and whom they are working with. After two years, I decided to set up my own offices. And still I work with a few suppliers, but that’s three or four from the thirty or forty that I have involved. Now we are a local offshore provider in Holland, Germany, Sweden and Denmark, with offices both offshore and nearshore. I strongly believe that the road to success in offshoring is much bigger by engaging a company like mine than to work directly with providers offshore or nearshore. Unless you are very lucky, you will go through the same process as I did. 

5. Choose country or location

There are good and bad suppliers (and people) in every country. And each country has other pros and cons. My personal vision is that the above three criteria are by far the most important to use in your selection. If you get your own vision regarding the why and how clear and find a supplier that has a similar vision, you are bound to have a match. Country in that case doesn’t matter. 

For some criteria to select the right country if that’s your basis for selection, please read this article. 

Additional criteria

The first three criteria determine your success. The fourth has some additional influence. If you are still in doubt, you could use some additional criteria/tips like:

- How (fast) does the supplier respond to your request for information?
- Talk to some references
- Check for stability and track record
-  Review some sample projects or case studies
- Have a skype call with the key offshore team members
- Do I have a good feeling about the account manager / the company?
- Pricing 
- Do a trial project or trial period first 

‘OFFSWING’ is designed to benefit the companies concerned by giving feedback about the management of soft issues in their offshoring processes, and to benefit Swedish-Indian offshoring relations in general, by gathering and disseminating knowledge about such issues which  have proven to be problematic. This project is supported by Uppsala University and Linköping University in Sweden.

Minna Salminen-Karlsson, assistant professor in sociology, has done research on engineering education and ICT companies since the first half of the 1990’s, as well as on women’s careers in technological work in a European perspective. In particular, she has been interested in computer engineering culture: how it is transmitted in engineering education and how it is formed in highly technological ICT workplaces. She has also researched learning in ICT companies, in particular the learning that takes place in team working processes. 

Interview Transcript

• Why have you decided to study ICT offshoring between Sweden and India?

Minna Salminen: We are a couple of researchers who have done research on gender relations in Swedish computer companies. We realized that these companies are increasingly going global, so we wanted to broaden our research area, too. And when they go global, new issues, such as culture and communication, become increasingly important.

• What are the factors that drive Swedish companies to outsource to India?

Minna Salminen: I don’t think there’s anything that’s specific to Sweden in that respect. In the beginning it was the cost. Now, I would say that it’s increasingly the talent pool, even if cost, naturally, also is a very important aspect. Swedish companies also become more international by mergers and joint ventures, and in that way come into contact with companies who already outsource. Some companies also seek to come to the Indian market with their products, and outsourcing can be a first step in business cooperation or learning to know the Indian setting. 

• What are the main benefits for Swedish companies when outsourcing to India? 

Minna Salminen: That is also something that is not particular for Sweden. Cost and talent. Something that I’ve heard that might be a bit special for Sweden is the need to structure up the work in Sweden to be able to outsource it. Some companies think it’s a benefit to be forced to do it, as Swedish company culture in general often is not that good in structuring and documenting.

• How does the communication between Indian and Swedish companies work? Do you have positive and negative examples?

Minna Salminen: There we have some issues that seem to be specific for Sweden. First, of course, it’s the language issue. English is not the first language for Swedes and many Swedes prefer conducting their work in Swedish. Learning to understand the Indian pronunciation in particular can take some time.  When it comes to more overall issues the reluctance of Swedes to be precise in their requests, in their follow-up and in their feedback, and the reluctance of Indians to say no to a request can cause a number of problems. The positive examples are there when both parties have found a functioning way of handling that difference and are personal enough so they perceive each other as real colleagues.

• Do you think there is something Swedish companies can do to prepare themselves for working with Indian companies?

Minna Salminen: To start with, try to get acceptance for the idea among those people who are affected by the cooperation. It’s not always easy, because outsourcing to India always actualizes the question of redundancy in Sweden.  If possible, meet the partner in person, either by going to India or getting people from the Indian partner to visit Sweden. It’s not always possible, but it often helps a lot. Some general cultural training might be good, I’ve heard different opinions about how important that is, but it’s good if people have a general understanding of the cultural differences that directly affect the work. However, that’s not always easy to do, and it’s also important to beware of confirming stereotypes about how “Indians” are, because there are both general patterns and individual differences. Learning to communicate clearly and precisely is important, but I don’t know how much you can train that beforehand, and how much has to come when you start working together. 

• Do you think outsourcing to India leads to loss of jobs for Swedish employees?

Minna Salminen: Yes, I know it does.

• What did you find out from your visit to Bridge India office? What was your experience?

Minna Salminen: It was fascinating to see a small multinational which is very different from the big multinationals, and also to see how people work with small clients. It becomes more personal and the Indian employees get more space to really try to attend to the customer. Bridge was also the only company I visited outside Bangalore, and I think the mentality is different in Kochi – an Indian developer I met in Sweden said it would be, and that was true. The pace is calmer, the people more relaxed, which is a bit more like Sweden. Compared to the multinationals in Bangalore it seemed like more fun to work at Bridge, and when you enjoy work you also do a better job. I know Bridge does a lot of work to bridge the cultural differences, but until I’ve talked to the customer side, I cannot really say how well that works.

Sini Jince(Bridge Blog admin): Thank you Minna for sharing this information and Visitors, please leave any questions or comments you have for Minna below and thanks for reading!

Organisations are traditionally: a place where people gather to work on something they are specialized in to create a certain service or product. Last century this place was often a factory and in the second half of the century, we moved into a service economy and the place became an office. In that office, people come in the morning, sit behind their pc, do their work and go home. 

The past years, home-working has become more popular. Instead of travelling every day, waisting time in traffic jams, people work from home. And some companies have even started engaging people remotely from other countries in their organisation. This is possible because we have the technology to communicate from home as if we’re in the office. We can share files, use online tools and we have replaced local servers by cloud-based servers. But still many people are conservative and believe that people should work from their office. What should we do to move into an organisation model with a global workforce? And WHY should we? 

The benefits of a global workforce.Why should we change our model of organizing?

• Talent: By tapping into the global labor pool, an organization has a much higher chance of engaging the brightest minds.
• Easy availability: In the US and Europe, there is a lack of skilled people and this lack will grow.
• Cost savings: The salaries in many countries are lower than in your country.
• Flexibility: Usually people are hired globally as freelancers or through a local company. The people are then not on your payroll and you can engage them per project or for the period that you need them. 

What should we do to get organised for a global workforce?

1.    Adapt a different mindset

The people that we now work with should become supportive of working with people from another country, another cultural background. People need to get out of their comfort zone; out of the belief that it’s much easier to have people sit in the same room, speaking the same language. 

2.    Re-organize how we work.

Organizing is basically a sequence of things people do to get a certain outcome, a process. We need to look at our current process and think what we need to change to work with people that work remotely. Most processes work sub-consciously, they are routines, grown by just doing what we do. In order to adapt the way we work, we need to draw or write down our current process. Then re-map this process and make a new drawing or description. And then reflect, re-organize and grow a new routine. 

3.    Select the right tools 

We need to select the right tools to support working remotely. This is different for every organization. There are some ‘best practice tools’ like basecamp for managing projects, github for version control in software projects. I have recently written an article with a more complete overview. Yesterday I went for dinner with one of our clients who aren’t fond of process and procedures. Nevertheless he did develop some tools they didn’t use as much earlier. They do everything with the tools Google provides: Google docs for managing requirements, Google sheets for tracking projects and time spent, Google hangout for communicating, Google drive for storing ‘traditional’ documents. In any case you need to select tools to: A. manages projects; B. Track time; C. Communicate verbally and written; D. Share files. Select one tool for each of those four and you have the basis for managing a remote workforce. 

4.    Practice, learn, and improve.

It takes time to build the right routines, because the people involved need to learn. With the right mindset, the willingness to learn and continuous improvement, your company can achieve the benefits of a global workforce. 

Avi Elkoni wrote an article for our blog about the 5 lethal mistakes in offshore software development. The first lethal mistake is downplaying cultural differences. I absolutely agree that culture has a big  impact on globally distributed software projects.

I have recently read a book about cultural differences that deepens the research of Geert Hofstede.  The commonly used framework of Hofstede explains national culture using five dimensions: Power Distance, Individualism vs collectivism, uncertainty avoidance, masculinity vs femininity and long term vs short term orientation. While reading the book I tried to picture the cultures and the people that I work with on a daily basis into this framework. And my general opinion is that although the framework can help to put national culture into perspective, in real day to day work with human beings, it might also make things more complex. There is a risk of over-analysing individual behavior using abstract concepts that aim at explaining a culture. 

People that work in my company for some time, seem to get used to working with Europeans. When we hire new people, we always stimulate certain aspects to overcome cultural differences. But when we ask our colleagues after 2 years what it is that they do differently, they won’t be able to explicitly tell you. People learn, people adapt. Theories help, practice helps more. 

Based on my practical experience, there are 5 aspects of culture that global teams need to pay attention to: 

1. Accept that there ARE cultural differences

The starting point for working with a global team of people from different cultures is to acknowledge that there are differences between team members. There are always differences between people, even in local teams, but with different cultural backgrounds, the differences are bigger. 

The behavior that causes conflicts in the team: stick to your own view of how people should behave and how things should go. The behavior that will enforce the team bonds: acknowledge, analyze and discuss cultural differences. 

An experience to explain this. As a Dutch, I am used to people being direct. People say what’s on their mind (and I am from Rotterdam, where this directness is more blunt than friendly). If people don’t agree, they’ll tell you straight in your face, even if that hurts your feelings. People in India are the opposite: they won’t tell you openly what bothers them, especially not if you are the boss (or the client). They will avoid hurting your feelings. Now when I stick to my Dutch behavior, I will scare every colleague away, I will ensure some of them will run into tears. Having said this, I am also confident that I have done so, because even while I am aware of the directness or even bluntness, my automatic way of communicating is to be straight to the point. Whenever I am aware of a remark that may hurt my colleagues, I try to apologize right away and explain my behavior.  

2. Don’t confuse culture with the right people

Your key challenge in building a successful global team is getting the right people in the right seats. You can find good and bad people anywhere on earth. An experience with one company or person doesn’t mean that all people in a country are the same. When offshore teams face difficulties, most buyers analyze the problems on the level of culture, instead of the person. 

3. Stimulate responsibility and pro-activeness

This point may already be biased by me being a Dutchman. In our culture people are usually expected to be pro-active, to come with their own ideas and suggestions. By contrast, people in India are raised in a more hierarchical way: the father is the boss and tells the kids what to do (or is it the mother?!); the boss is the boss and we listen to him. Because the boss is the boss, it is not ok to tell him he’s wrong, to pro-actively suggest an idea that is conflicting with his idea. 

Teams grow successful when the individual team members take responsibility. Software becomes better if more brains add ideas to the software. Things move faster if every team member is focused on pro-activity, doing things, execution. It is crucial in any team to clearly describe responsibilities and then to stimulate people in taking responsibility. 

An experience. In our company, we have removed all hierarchy. In our offices, there is no boss, there are no project managers and only team leads if the team consists of more than 3 people. Every programmer is responsible for his own work and gets direct feedback on his performance from the customer. That feedback affects his salary. Programmers also speak directly to their clients, there is nobody in between. We continuously stimulate people to come up with their own ideas and suggestions (usually this is also one of the points in the performance review of the client). Every day I repeat that I appreciate feedback, I appreciate their ideas and suggestions. We have daily and weekly meetings so people always have chances to express their opinion. 

4. Stimulate openness

I am a firm believer of openness and honesty, at the risk of being too open. So again this tip might be biased by my (cultural) background. In working with different nationalities, my belief is that the only way to understand each other is to be open about everything. When the behavior of one person insults you or affects your work, the other needs to become aware. He can only become aware if you tell him. 

On top of the cultural difference, people work remotely from different locations. If the project manager is in the Netherlands and the programmers in Ukraine, both ‘sides’ won’t have the chance to see what’s happening on each side. They miss the talks during lunch, they are not aware of any conflicts among team members. Unless everybody openly shares what’s going on. 

A practical case. We had a team of 6 developers working for our Dutch customer from our office in Odessa. By agreement, salary hikes are decided by this customer. But the agreement with the developers is made by our local Ukrainian CEO. Two developers wanted an increase in salary end of 2011. The CEO informed our customer about this and the customer needed time to decide on this. I learned that most developers that ask for an increase in salary in Ukraine, want it NOW. If they do not get it, they will have a new boss within a few days. The decision from the customer took some weeks and away the two developers went. If we had had an open discussion between the developers and the customer. Or between our local CEO and the customer, then we could have discussed a solution and we could have found a compromise in salary or change of roles. 

5. Reflect continuously  

Being open about each others behavior is the basis for understanding. To facilitate this, it helps to have regular review-meetings. In a new team, it is best to do this every week. In this meeting, the members can reflect on the progress in the projects, on the communication, on the behavior of each member. By discussing all these topics, (cultural) differences will come to the surface. We can address them and people can adapt their behavior. 

These five tips can form the foundation for growing a highly productive global team. If people embrace the differences and enjoy working with different people from different nationalities, the work can be a lot of fun. 

As I’m sure you’ve heard, there are far-away lands where the best and brightest youths flock to science and technology schools. They emerge a few years later in hoards of brilliant and eager software developers. Why not put them to work for you? They are smart, talented, easy to find and hire and they work for very reasonable pay. The big guys have been doing it for years and recently, smaller and smaller startups are incorporating offshore development into their plans.
As a development manager I have, over the years, utilized development teams in India, China and Russia. Here are some lethal mistakes to avoid: 

1.Downplaying the culture gap

Communicating with your offshore developers may seem easy; in all likelihood they speak decent English. A friend of mine, a European microbiologist who hosts in his research lab science grad students from all over the world, commented that in recent years the level of English spoken by young foreigners has improved dramatically. I think he’s right, and I believe that what we’re seeing is a generation of young people, now in their twenties, who speak good English because they grew up with Internet access and were exposed to a lot of English content.
But beware: culture is much broader than language and communication has a lot more to it than words alone. Intonations, gestures, idioms, slang, vocabulary, unspoken assumptions, acceptable and unacceptable behavior vary wildly across the globe and these variations can lead to catastrophic failures in communication. The fact that good English is spoken on both sides might lull you into thinking that you understand each other when in fact you do not. 

To avoid this mistake:

Encourage offshore participants to explain back to you their understanding of a conversation (especially if the conversation is one-sided in nature, e.g. you are assigning tasks or briefing them on a new initiative).
Document and share meeting minutes; writing gets the non-verbals out of the way.
Mind the gap; keep reminding yourself of the cultural differences that you must bridge. 

2.Managing offshore developers remotely

The whole point in offshoring is to save money, right? Excellent offshore developers are sometimes easy to come by, but hiring good managers is never easy and not nearly as cheap. You might be tempted to skip hiring a manager altogether, tap into the startup spirit and “do it yourself” (that is: manage your offshore developers yourself, remotely). My advice: don’t!
Managing people is hard, managing developers is harder. A software development team’s manager needs to be there with the developers, meet with each one on a regular basis, get a first-hand account of their activity, successes and challenges. Unless you are an expatriate offshoring back home you already have a cultural gap standing between you and your remote team. Add to that the time zone differences and the loss of non-verbal cues that come with long-distance telecommunication and you have yourself a recipe for failure. 

To avoid this mistake:

Hire a local manager for your offshore team. If the team is small (less than 5-10 developers) you can hire a “working manager”: a senior developer that also happens to have management skills. If your team is larger than that, hire a full-time manager. In any case you must have a single point of contact and accountability on the ground, close to your developers and on the other side of the geographical and cultural gaps. 

3.Skimping on travel

International travel is expensive, time-consuming and uncomfortable. With video conferencing and web meetings readily available you feel like you are virtually there, but “virtually” does not cut it. If you don’t travel to visit your offshore team you might never interact directly with some team members (usually the more junior ones), you will never get a feel for the atmosphere in their office, you might never know what is working well and what isn’t. If you never visit your offshore team you are relying completely and blindly on your remote manager, creating a dangerous single point of failure in your organization. 

To avoid this mistake:

Every six months or so clear some time on your calendar, make sure your passport and visas are in order, get a plane ticket and pack your bags.
To make things a bit easier, alternate between traveling to visit your offshore team and inviting your offshore counterpart to visit you. This will give your remote manager an opportunity to interact with other members of your local team. Travel can be a burden, but in some cases your remote manager may see these trips as an added benefit. 

4.Failing to protect Intellectual Property

Coders handle one of your company’s most valuable assets: the code. At home you are protected from code theft by non-disclosure and confidentiality agreements, ethical norms and the legal system. Personally, I never encountered a developer that stole source code and sold it to a competitor. Both the developers and your competitors have too much to lose in terms of reputation and legal liability (both civil and criminal).
In a foreign country, do you know what the social norms are? Will the social norms protect you? Can you enforce a non-disclosure or confidentiality agreement? Can you count on the legal system? If you fail to answer these questions before trusting your offshore developers with critical parts of your code you might find yourself up the creek without a paddle. 

To avoid this mistake:

Get sound advice, specific to the location of your offshore team. Do not share critical portions of your code with developers in locations with a questionable confidentiality record. 

5.Placing marketing functions away from the target market

This mistake is common among foreign companies that start out with a development center in a low-cost locale and develop a product for the US market. Once product development is complete they would open a sales office in the US and leave product development,QA, tech writing and other functions back home where things are more reasonably priced. It hurts to spend big bucks on a US sales force when you have grown accustomed to much lower costs, but you know there is no escape from it.
But what about marketing functions? Do you really have to hire super expensive US-based product managers? Lead generation is all done via telecommunication, it’s not quite the same as sales, is it? And what about collateral writing, does it really have to be done at $80 and more per hour when your brightest developers work for less than a third of that?
The answer is yes, you have to spend the money and keep your marketing functions close to the target market. If you don’t, you are wasting your money on your US-based sales team. Instead of results, they will deliver a constant flow of complaints about the quality of leads, marketing materials and product features. 

To avoid this mistake:

Once you commit to the US market, hire a local sales and marketing team, don’t blunt your own competitive edge with a marketing team that is not in touch with its own market.

Via, http://murkygrey.com/?p=112

Dear reader,Have you had good experiences with offshore development? Do you have international outsourcing stories?

Business needs for improvement projects are changing. Organizations expect faster results from their investments; they want their improvement projects to adapt to and follow changing business needs and be more engrained with the organizational way of working. The agile way of working, used more and more in software development, contains several mechanism that support these business needs. So the question is: Could an improvement project be performed in an agile way, and what would be the benefits?

Why use Agile for Improvement projects?

There are a couple of reasons to work agile in improvement project. It helps the business to adopt improvement projects to the changing needs, thus getting business value. Which includes making the value visible, and discussions on the value can be expected from the improvement project. Agile also helps to engrain improvement in the way of working of an organization. Many organizations have or are adopting agile development methods, and use techniques like retrospectives to continuously improve on a team level; it feels natural to adopt similar mechanisms for organizational improvement projects. Finally, since there are always limitations in lead-time and money (available hours of the team and of the organization that need to adopt the changes), you have to work efficient. Agile helps improvement teams to deliver quickly, and deliver maximum value with a limited budget. So altogether there are sufficient reasons, from a business point of view to adopt an agile way of working for improvement projects.

Delivering Training in an Agile way

I worked with a customer that wanted to measure and control the quality of their software products. We agreed to work on-site with the teams and management for a week, to train and coach them. In stead of making a plan for the full week, we only planned the first two days with a kick-off presentation, workshops, and daily evaluation and planning at the end of each day. This would make us flexible towards the needs of the various teams, which would become clear during the week. I made a short list of available trainings and workshops, and my customer picked the ones for the first two days. I also gathered and organized my presentation and training materials, to have them on-site during the week.

In agile terms: As a 1 man Team and Scrum Master I created a backlog and my Product Owner (customer) prioritized the User Stories (trainings, workshops, presentations) and picked the ones for the first two sprints (day 1 and 2). We decided to have a stand-up every morning to check the planning for the day, and to have a daily retrospective and planning game at the end of each day to evaluate the day and fix the planning for the next day. It would be a training week with 5 sprints of 1 day.

After the first day on-site, we did an evaluation (Retrospective!) and decided that we needed some small changes on day 2 (Planning Game!). We also made a draft planning for day 3, which included a new course to be developed (using partly existing materials). This way of working (Sprints!) was used throughout the week.

Additionally, on the 3^rd and 5^th day we had a short evaluation/planning session with the whole MT. On the 3^rd day, the MT asked me if I could do a presentation of how an organization could look that would use a full blown quantified quality management system. This was a pleasant surprise for me, as I didn’t expect that they would be willing and ready to take this step. I adapted a presentation that I’ve given as a keynote on a conference, and added specific slides on what we had done already in the past days. It was a great success; it helped the attendees to visualize how their “road to quality” could look. The employees asked lot’s of questions, and there were several good discussions between the managers and the employees, about the reasons to manage the quality of their products, and what the management can do to facilitate this. Neither the customer nor I would have expected this when we started the training. By working with agile daily sprints, and continuously adapting the training we were able to make it more valuable!

You might be wondering if anything went wrong, or if there were things to improve? Of course! Since every day ended with a planning game, I always had some “homework” in the evening. Incidentally this posed a challenge to have training materials ready for the next day, but I always managed to do it. On the 1^st and 2^nd day we had some training sessions which took more time then planned. Actions taken were to become more focused in the training sessions, and also allocate some more time for the sessions, or slack in between training sessions, to meet the schedule. With these improvements, we managed to met the schedule for the remaining days.

Summing up, Agile practices helped to deliver this training week and make it more valuable. The daily retrospective and planning game took only 15 minutes at the end of each day, and helped us to adjust the training to the changing needs. Every morning before the training started we had a short stand-up of 5 minutes to check if everything was ready. We didn’t really have a demo, but since my customer attended almost all trainings and workshops you could consider the full training day to be a demo. Where my customer could not attend, I briefed him on what happened when he rejoined the training. In the final evaluation on day 5, our conclusion was that delivering the training in this agile way had been very effective and efficient.

Process Improvement, the Agile way

The agile approach has been also been used in two process improvement projects, the first project for improving process management activities within a business unit of a multinational company, and the second to do selective and quick process improvements, in an R&D center to continuously improve the performance and results.

The projects used Scrum as method to coordinate and collaborate. The manager responsible for processes within the business unit was the Product Owner, who made user stories that described the services and products that had to be delivered by the Team. Given that this was an improvement project, the products produced were presentations, slide sets, and documents containing policies and text for the intranet or newsletters, and tasks that had to be done, like arranging discussions, workshops and meetings, and taking and communicating decisions.

The team consisted of professionals involved in operational development at the R&D centres. They were very experienced in process management, but most of them never worked in an agile team before. Based upon my agile experience, I became the agile coach, helping my fellow team members on how to fill in the different Scrum roles. I also organised retrospectives at the end of each iteration, and supported team members to implement the improvements that were suggested in the retrospectives into iterations.

We had a backlog with user stories from our product owner, and a first planning game at one of the R&D sites, where all team members gathered with the scrum master (our former project leader) and the product owner to discuss and define a first sprint, and agreed upon the user stories, and how we would do our “stand up” meetings, use a wiki to collaborate, and do the demo for our customers and the retrospective to learn and improve as a team. We decided to work in sprints of 3 weeks. The demo’s would be given to the product owner, and we would invited relevant members for our organizations to attend and give us feedback.

The wiki was our task board, and communication tool both within the team, and from the team (including the product owner) towards the organization. The project plan was a wiki page, which included the goal of the project, the way of working (our process), and contact information of all team members and stakeholders. Also the backlog was on the wiki. This created visibility for the improvement project; both in the communication within the team and from the team to the stakeholders. Planning games were done by telephone conference, where the scrum master continuously updated the wiki during the meeting. The user stories and engineering tasks were added, prioritized, and checked by the team which at the end of planning committed themselves to deliver the required functionality. The demo consisted of a phone conference with presentation. Team members and the stakeholders either joined in from their workstation, or (if multiple people were at 1 development site) arranged for a conference room with a beamer and hands-free telephone connection.

It took a couple of iterations to tune our “definition of done”. Having a presentation or document made was not enough, so we decided that a task could only be done if the products had been reviewed and commented upon by at least one other team member, and the product was updated based upon the review comments. Of course all documents and presentations had to use official templates and comply to the corporate standards, but this was something all team members were already familiar with.

Looking back there were several benefits from the agile approach as we used it in our global process management project. The main benefits that we saw were:

• Being able to deliver the right product with high quality, using frequent feedback
• Understanding the strengths & weaknesses of our processes, and the business value
• Alignment and streamlining of processes between several R&D centres
• Efficient ways for professionals to work together in a dispersed team

We were able to produce many documents, newsletter, slides sets and supporting material that the local R&D centres could use to align and improve their development processes. Though we have no hard figures, our impression is that it took us less time then usual to make them. An even bigger benefit was that the quality of the products delivered by the project was very high, and there was a strong commitment for the changes proposed by the project, due to the frequent planning game and demo meeting where we aligned with our customer and the stakeholders. Several R&D centres started to use the material while it was still under development to do their local process improvements. This helped them to start quickly, and come to results faster, and it also helped our process improvement project since we got feedback from the local improvement initiatives and were able to update our products along the way. All together the commitment for the process improvement initiative was high, both at a business unit level and at the local R&D centres.

In the retrospectives that we did after every 3 week iteration we discussed how the team member had experienced the agile way of working. It took some time initially to develop an understanding of the roles, and how to combine the team role with the local responsibilities of the team members. This because the team member had two roles in the team. First they represented their local R&D centre and acted as a linking pin to local process support teams, and the local management. Second they brought in their experiences and skills with process management. The aim of the team was to enable team members to contribute as much as possible from their experience to the result, increasing the effectiveness of the team as a whole. This resulted in team members picking up different tasks, depending on where they saw the biggest possible contribution. If we saw that higher priority tasks were not picked up, we discussed this in our stand-up, ensuring that they would be done in time before the iteration finished. This task approach could be conflicting with the representation role that team member had, e.g. in situation where certain process documents were to be made by a team member which would not be of use for his own organization. Where there were potential conflicts, we discussed them in our stand-up meeting, and we always managed to come to a solution. That could either be that another team member would pick up the task, or that the team member would make a first version which would then be extended by other team members based upon their experience. Though being dispersed, we managed to work together in pair where this benefitted the team. All team members were very positive about the agile approach, which enabled them to contribute to the end result. Also they valued the support of the other team members, which helped them to learn from each other, and to further develop their process and change management skills. 

Conclusions

This blog described how we have applied our experience with agile into training and process improvement projects. Scrum was used a as method to iteratively deliver a training, and products and services for process improvement. Retrospectives, stand-ups, and a wiki and telephone conferences were the main tools to manage the work and deliver results. Using agile, the training week delivered more value for the customer. The agile approach has shortened the lead time in process improvement, gave a better understanding of what our customer needed, and increased the commitment for the changes that were needed in the organization. The team members and customers appreciated this way of working since it helped them to continuously contribute value, and to develop their knowledge and skills.

More information 

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

• Golden Rules for Agile Process Improvement
• What Drives Quality: Senior Management
• Getting Business Value out of Agile Retrospectives
• Measuring and Controlling Product Quality
• Using Scrum for Process Improvement

About the Author:Ben Linders has a broad international experience, specializing in quality, process improvement and organizational development.  Team worker, driven, supportive, and pragmatic. Committed to quality business results on time, continuous improvement & development of professionals.

Agile, Scrum, Lean, Six Sigma, Retrospectives, Lean Startup, Kanban, CMMI, People-CMM, Root Cause Analysis, Open Space, RUP, EVO, Props, Prince-2, ISO 9001, EFQM.

Email:              info@benlinders.com

Twitter:           @BenLinders

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

The Hackett Group published an interesting research about the future of offshoring. They did the research among 4700 companies with $1 billion in turnover or more. The researchers predict that by 2016, 2.3 million jobs will have been moved offshore from the US and Europe. This represents 1/3 of total jobs in IT, finance, procurement and HR. 40% of that goes to India. 

At the same time, the EU will have a shortage of 700.000 people in IT by 2015. 90% of all jobs will include an IT component. The IT sector is growing rapidly as companies become dependent on IT systems for operations and growth. So companies have a big incentive to move jobs offshore or nearshore. 

The question is how far can offshoring go? Will there always be more jobs to move offshore? The Hackett Group predicts that by 2014, the levels of movement will begin to decline and in the decade after that, will come to a halt. By 2022, they predict that all jobs that can be moved, will have been moved offshore. 

I strongly believe that companies gain more experience with offshoring and based on that experience, they can organize more work with a global workforce. What I wonder about is the speed of this movement. The past 6 years I have been involved in offshore and nearshore IT outsourcing. What I see is that the US is offshoring much more much more easily. Europeans are very reserved as they all have considerations about language and cultural differences. The past 6 years, I have seen IT outsourcing become much more ‘normal’. But I believe Europe still has to see the biggest growth in the next decade. I sincerely hope that European companies will offshore as much as the Hackett Group predicts. But I doubt that this will happen fast enough to fill the gap of 700.000 people. 

Dear reader,What is your vision on this? Will we move 2.3 million jobs offshore in the next decade? Will we move every job that can be moved before 2022? Will the speed of offshoring from Europe match that of the US?

 Last week, I gave a presentation at the Technical University in Delft and one of my topics was ‘empathy’. I always get some questioning faces when I present a slide with a definition of empathy on it. Normally, technologists get taught about rationality and data, not about people and emphatic relationships. 

The definition of empathy that I used: Identification with and understanding of another’s situation, feelings, and motives.

In my vision, empathy can help offshoring cooperations on several levels. The first level is in bridging the cultural differences, the second level is on the work itself (people, company and project). 

* From there we can organize around the differences: collaboration. Once we acknowledge that the differences ARE, we can find ways to manage around the differences. If for example, we acknowledge that in India, people say ‘no’ in a different way.Watch this video! We can use a different type of questioning to find out if they agree or not. Or we could spend some months in India to find out how this Indian yes-no works. 

* If we do not accept the differences, cooperating can lead to frustration. I have seen in many cases that if a person holds on to his own world view and his own values, it can lead to frustration because one gets frustrated that the other person doesn’t share his views. And this frustration can also lead to project failure. 

Second level: Empathy in the works or projects

In the work itself, it helps to stimulate empathizing:

* Among team members: invest in trips. It helps if the onshore and nearshore team members meet eachother (regularly). People bond when they drink a beer or eat a chapatti together. This bonding promotes understanding and helps the team to produce better results. 

* With the company culture: mission, vision, values. The offshore team doesn’t drink coffee with you in the morning; they don’t speak to the CEO who expresses his vision day in and day out. In the ideal case, the offshore people consider themselves colleagues and an essential part of the company. In order to realize this, they need to identify with the value system, the reason the company exists and the direction it is heading. 

* With the products: Who uses them? Why? How do we earn money? Often, the onshore team has a deep knowledge about a software product. They have built it, they discuss it every day and the product is ‘alove’ they also live in the country where the product is used by people. For the offshore or nearshore team this is different. Transfer of domain and product knowledge is important, especially in the beginning stages. People offshore need to identify, empathize with the products and get a deep understanding.  

Related articles

Indians can’t say no, fact or fiction?

How software developers can overcome Cross-Cultural Communication mistakes in IT offshoring?

What tools do you use for managing global 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…

However, one must be fully aware of the dangers of outsourcing that is often directed on the security of the business. The boom in outsourcing made most companies believe that there is no other option for them to reduce their operating costs. And for small businesses who do not have the financial power to establish their own outsourcing division, they often end buying these services for third party providers. The major disadvantage is that big BPO providers handle various business processes for more than one client and this includes competing business institutions. Without prior concern to security, some companies may unsuspectingly expose some of their confidential business operational system. If a company will not filter their choices of business process outsourcing companies, they end up using the services of an outsourcing provider that may have other agenda like selling a company secret to other competing business institutions or collating all the necessary data and set up the same business model using another company’s operating system.

The main thing you need to look for before finalizing an agreement with a BPO provider is the league of expertise they can provide to your firm. You need to evaluate whether the BPO company is also offering the same services to your major competitors in the business. If they do, you may want to consider looking for another company that can offer the same range of BPO services that is not dealing with other companies you consider as your direct competitors. One of the crucial ways to look for good standing BPO firms will be to choose for a follow up with some of the existing clients of the company and their related services. Your chosen BPO provider must be able to provide you with quality certifications. Furthermore, these providers must also have the capacity to provide a skilled workforce that can meet the client’s requirements for quality work.

In addition to quality standards, business process outsourcing companies must also have a strong financial background. When you choose a BPO provider, you need to ensure that they have a solid financial condition which is needed to meet your project. Capital is always needed when it comes to buying raw materials, hiring people, and other activities related to business management. With solid financial capacity, BPO providers can guarantee on time delivery without sacrificing the work quality.

To learn more about outsourcing and get your free copy of my book, ‘Outsource This!’ visit http://www.123Employee.com.

Daven Michaels is an award-winning outsourcer and author of the book, ‘Outsource This!’ Daven has been honored more than any other individual or outsourcing organization. You can get more information on outsourcing by visiting http://www.123Employee.com