Of Frogs and Wrestlers
So you found a new vendor, negotiated a perfect deal and established relationships with key players. The team starts its work and shortly you can realize the savings you’ve been looking for. A year passes faster than you could ever imagine. Reports coming from the vendor showing good compliance with the benchmarks you established. You about to give yourself a pat on the back for being such an incredible offshore manager. And just to be a good sport you take a few business users for a dinner to share with them the wonderful achievements of incredible you.
Unfortunately even before you are done with the first round of drinks the conversation takes a rather unpleasant turn. No, they are not happy with both the quality of work your offshore team has been providing and their productivity. They are afraid of changes to be done to the systems your offshore team supports, they do not submit bugs because they are afraid that fixing one new bug would re-open a dozen of old ones; they do not enter RFEs because they do not believe they would ever be delivered, and so on.
What just has happened? All that rain on your parade is coming from a completely left field. Read more »
Offshore QA and a Sly Fox
A fairly common model for working with an offshore vendor for SaaS companies is based on black box model – the requirements collected locally go to offshore team and code ready for production comes back, sometimes in a form of binaries. There are variations to that model with the same common thread – the full responsibility for development of the application and its quality assurance belongs to with the vendor.
Can this approach work with an arbitrary software development shop? Absolutely! As a matter of that is the model used by all ISVs that do not employ offshore, so model works for sure. The question is whether offshore components in that model make the difference worth discussing, and unfortunately they do. The fundamental laws of outsourcing (FLO) affect efficiency and reliability of the model to a great extend, often making the model completely unreliable.
There are so many things that can go wrong inside of the proverbial black box turning it more into a Pandora’s Box:
- Communications issues and information loss at every handover
- Ever deteriorating quality of the resources
- Inevitable deterioration of the quality of code
- Growing blind spots in test coverage
- And so on – you can continue this list ad nauseum
Offshore BC & DR
Thinking about Nostradamus predictions for 2012 and all cataclysms that will strike that year? Afraid and developing your bullet proof Business Continuity and Disaster Recovery (BC&DR) plans? Well, if meteors, super-volcanoes, and melting ice caps flatten, burn, and flood most of humanity those BC&DR plans won’t matter much. However, increasingly more powerful floods, hurricanes and earthquakes with enormous toll remind us about vulnerability of even rich nations such as the USA, Canada, or China…
As I pointed out in Force Majeure working with offshore organizations increases risk of substantial losses bring up the importance of having solid BC&DR plans. Of course if you are working with a mature offshore partner they would have their own BC&DR plans. That’s great with one important caveat – will these BC & DR plans work when needed?
It was not long ago when supposedly invincible 365 Main Data Center in SF went lights out for a considerable period of time after a scheduled (!) black out. So there are a number of questions you need to answer:
- Does you offshore vendor has solid BC&DR plans?
- How often are theytested?
- What are the KPIs / metrics associated with these plans?
- Are those metrics sufficient for your business?
- Who audits these plans and activities? (You won’t take the vendor word on it, would you?)
Well probably the first set of questions you should address to yourself or your IT team responsible for BC & DR. Interestingly enough for many, especially small companies the answers from internal team are likely to be much weaker than those from offshore. And as a matter of fact for some offshore is the BC & DR plan.
After you covered two main points you need to check the route between them. There are many aspects to connectivity between offshore and onshore. Things can get lost on the way, connectivity may drop (if major cables are damaged for quite some time as it happen with India couple years ago). But even more important is to make sure that was sent to you is indeed what you expected and that it is what you received. Wrong code pushed to production (happens even to Google) is sometime more serious disaster than interruption in service. That gets into an area that deserves a lot of discussions by itself – QA and in particular acceptance testing. I will cover it in a couple of posts in the future.
One more major aspect to consider – what if the relationship between you and the vendor go sour? In one or another way – you did something wrong, vendor decided to rob you of your IP, etc. There are plenty of sad examples. That kind of disaster is most difficult to deal with. And with them being as unpredictable as the Acts of God you should have solid BC & DR plan for that as well. Starting with solid contractual framework, appropriate and frequent archiving, and so on. Yet you can’t be ready for everything – losing key resources, knowledge transfer cost, etc. Not easy to deal with, sometimes practically impossible. However there is a good news, when it comes to these kind of diseases I know very reliable medicine – Disposable Outsourcing.
Environmental Fears
As I mentioned in At Doorsteps of a New Engagement I have a new vendor to deal with. It is a company that has been working with my team for over two years and thus it’s only new for me. It took about a few days for me to encounter the first set of issues. And that set came from the area so common that it’s worth a post by itself – software environments. Below is an email which I was cc’ed on –
Subject: RE: WCM Publish failed
Ravi,
Please explain to me how the production environment does not match what is in UAT. This is unacceptable and must stop. This is not the first time a production turnover did not match UAT.
We need to review our build, turnover, and documentation procedures. This pattern cannot continue.
Looks familiar? I am sure it is…
If you are in business of delivering software as a service or similar to it the chances you will have the following environments: development, QA, staging, production, disaster recovery. You may also have dedicated environments including Build, UAT, Sand Box(es), Performance Lab, etc. If you work with offshore team the chances are some of those environments are duplicated in the offshore offices.
A number of issues arise as environments proliferate:
More Thoughts on ESL
A while ago when still a student I stumbled upon a great supplemental income opportunity: a friend of mine, an editor in a science journal, was looking for part time interpreters. The task was quite simple: writing summaries of technical articles. To me my French even though practically non-existent seemed strong enough to do that maybe, just maybe, with some support of a dictionary. I stopped at my friend’s office and he handed off to me a half a dozen articles on various medical topics. I was quite flabbergasted and asked – why medical? I am a technical guy. Math, engineering, maybe software, but why medical? My friend just smiled – if I give you articles in your specialty I will only get back what you know of the subject, chances are, that everything new and or controversial will be missed, and that’s assuming that you know French well… After a few nights of checking every word in a dictionary and still not being able to put the puzzles together I decided to switch to different means of making money.
I have seen the same phenomena with many technology professionals for whom English is somewhat of a struggle. They often step back and rely on their technical skills in understanding their client needs, interpreting the information inflow, often to the detriment of the project. That in particular common for advanced ESLers. When working face to face with native speakers and not communication related misunderstandings are easier to address, non-verbal language and timely feedback are of great help in this case. When you introduce the offshore factor, the time and cultural differences on the top of language handicap communications mistakes accumulate and widen the gap in understanding. Technology professionals have a tendency to bridge the gap with things they are familiar with and make decisions on behalf of the client.
Dealing with this issue requires efforts on both sides and unfortunately there is no panacea. Trying to get every assumption documented and signed off is a recipe for a productivity disaster, leaving things up for interpretation by developers is asking for even more troubles. Many of the tools I find helpful and efficient in this case come from agile development practice, in particular short release cycles and frequent demos.
Of course learning English remains to be one of the most important tasks on the provider side. But with over 600,000 words it’s easier said than done. Classes and books will only get you a fraction of the way there. What can one do to continuously advance in that utmost important skill while keeping they day job? We take our chances and use different methodologies. For me motivational tapes from Brian Tracy, Zig Ziglar, and Anthony Robbins were the main tool not only in building the vocabulary but changing my Russian gloom and doom attitude. Some people listen to NPR some watch a lot of movies. Having mentioned that lat me share with you a story I hear from Kirill (offshore development manager for a large s/w company on weekdays and my blog reader in his spare time). He told me about a Russian developer manager who took watching movies to heart; he also combined business and pleasure and watched primarily action movies. Being very gifted in terms of language he built broad vocabulary of words and idiomatic expressions, a lot of idiomatic expressions unfortunately mostly borrowed from Dirty Harry wannabes. That did not do him particular well :( If you are working on your language skills here is Kirill’s advice –
One of my guys in St. Petersburg has outstanding English and I asked him how he had mastered it. He said that he listened regularly to free podcasts at www.eslpod.com. I checked the site out and downloaded tons (close to 5G) of historical podcasts. Topics are pretty basic, but the language they use and pronunciation is very good. I wish I had something like this when I just came over here :)
Well, as the say it’s better late than never – I’m signing up …
Offshore Impact: Personnel Issues
So you are moving forward with offshore initiative, maybe a new or expanding an existing one. What is going through the minds of your team members? What kind of questions are coming up? What is not letting them sleep at night? That’s not difficult to imagine:
- Is my job at risk?
- Is my salary at risk?
- Is my career at risk?
- Is my quality of life at risk?
- Is my project / department / team at risk?
Let’s start with a reality check: chances are there will be three groups of people easily categorized by the answers to these questions – Yes, No and Mixed / In between. There will be people who can lose their jobs or forced to take lower paying jobs. Transferring jobs offshore may reduce scope of career opportunities or completely eliminate some. Some people might be asked to work odd hours, and so on. Maybe some of the team members won’t be affected at all. And for some there will be a mixed impact. That impact on employees inevitably affects the employer, and as I pointed in my earlier post The Darkest Side of Outsourcing that impact could be very serious. That’s why minimizing negative impact of personnel issues is likely to become your primary objective as an outsourcing champion or the manager in charge.
One of the ways to do it is to tune into your team’s WII.FM station. What’s In It For Me? What is the silver lining of the offshore initiative for your team members? That of course depends on specifics of your organization and the scope of offshoring; here are just a few general ideas for your consideration:
- Offshoring might offer an opportunity to offload grunt work freeing up employees to work on more interesting / engaging projects.
- In similar manner offloading grunt work may allow organization and its employees to focus on core strengths and areas of competence.
- Sometimes offshoring opens an opportunity for the employees to learn new technologies / products.
- Management / leadership opportunities can open up.
- Specifically offshore management opportunities could be attractive option for career development. With offshore here to stay experience with offshoring can benefit many employees even those not involved in management / leading roles.
Let me repeat something I mentioned in The Darkest Side of Outsourcing: Associating introduction of offshore with layoffs – replacing local workforce with offshore resources is a double hit on remaining workforce with inevitable impact on employee morale and overall workforce quality:
- Employee motivation will disrupted with result in increase in political behaviors, anger, fear – which is likely to negatively impact quality of customer service, performance decline, and decline in quality of work atmosphere.
- “Survivors” experience more stress due to longer work hours with re-designed jobs, and increased uncertainty regarding future downsizings.
- Senior and the most marketable employees may leave with result in decline of overall quality and qualification of workforce and loss of institutional memory.
A silver lining here is an opportunity those events could represent for some of the employees: an opportunity to show one’s ability to excel under pressure, a chance to step up to challenge and learn new product, skill, fulfill the void left by departing employee.
In my experience I’ve seen that on numerous occasions – a problem creating a launching pad for capable but for some reason unnoticed or underappreciated employees.
The question is whether as the leader of organization you can carry on positive message and motivate the troops to take advantage of the opportunity rather than dwell on native events and unforgivable loses. Another question is whether you can deal with inevitable negativity and ripple effect of the changes. Here are a few things to consider for dealing with the personnel impact:
- Consistent non-stop communication. Check out 7 Cs of communications and follow those as much as you can afford considering the situation.
- Consistent aggressive motivation. “Motivation is like food for the brain. You cannot get enough in one sitting. It needs continual and regular top up’s.” [Peter Davies]
- Be prepared to pay above market. Hopefully offshore cost savings can offset some of the cost impact.
- Invest heavily in the staff redundancy. That is a complex issue that requires longer discussion, let me just mention just one aspect of it: staff redundancy will give you the confidence to operate in the challenging environment that offshoring is likely to create in your organization.
- Process and methodology changes / adjustments / improvements to create environment tuned to the new organizational layout.
The Darkest Side of Outsourcing
While writing a post on a topic of personnel impact of the offshore outsourcing I had to go through a rather unpleasant exercise – I had to terminate one of my employees. Termination is never fun, it is particular painful on a backdrop of economy downturn. Through my career I had to let go a great number of people, mainly due to the industry’s downturns / massive layoffs. Layoffs are painful yet the sheer size of the event makes it easier on everyone. Things tend to go much more close and personal when you have to let go someone on a performance basis.
Reaction of the person being let go on a performance basis is very difficult to predict and control. I have seen budges fly in my face, verbal explosions and threats, I have been in situations when I had to call security and once got very close to calling an ambulance. This time it did not go particular well either. The employee got agitated, angry and quite upset with the unfairness of the event. After the termination the direct manager of the employee and I started receiving harassing calls from a blocked number on our personal phones…
Sending jobs offshore is likely to create a few enemies. For example when I introduced offshore concept in Spear Technologies one of my key employees came back with a common in this case blackmail techniques: “I’ll quit”; he did not, just remained never ending pain in the neck. Two other people quit citing offshore decision as one of main reasons. If sending jobs offshore means layoffs things can get quite ugly. Especially if the laid off employees are picked on a performance basis, what is quite typical and the right way to go, especially in smaller companies.
Performance based termination rarely goes well, and sometimes goes exceptionally bad. It was not long ago when a laid off employee took lives of executives of his company in a Santa Clara startup. As my CEO put it “There is too often a thin veil that covers members of society and when the wind blows, the veil can come off. After 10 years in the emergency department I can tell you that apparently senseless violence is hardly rare. The details of this occasion are making headlines but frankly not the violence. Very sad to me is not just the violence but the lack of priority or even care for this guy’s own family. He destroyed more lives than he ended.”
I’ve written about potential pitfalls of outsourcing and will write more. You should move carefully and make educated steps when outsourcing, if your offshoring decision is causing / associated with local job losses be exceptionally careful. You could be making the decision based on spreadsheets and what if analysis, for better good, the company survival and bottom line needs; for you that might mean “nothing personal” yet for those who are about to face job search in today’s market it will be very personal. To minimize potential backlash consider a few general tips:
- Deliver clear and consistent communications with messages covering reasons, expected goals and objectives, as well as processes behind. The communications should in general precede the events and continue on long past them.
- Do not cut the jobs across the board. Rather, make the tough decisions to selectively cut jobs. Do not disguise performance based termination as layoffs.
- Focus on those who stay, yet remember that “survivors” will judge you / organization by the way layoff was conducted and downsized employees were treated
Associating introduction of offshore with layoffs – replacing local workforce with offshore resources is double hit on remaining workforce with inevitable impact on employee morale and overall workforce quality:
- Employee motivation will disrupted with result in increase in political behaviors, anger, fear – which is likely to negatively impact quality of customer service, performance decline, and decline in quality of work atmosphere.
- “Survivors” experience more stress due to longer work hours with re-designed jobs, and increased uncertainty regarding future downsizings.
- Senior and the most marketable employees may leave with result in decline of overall quality and qualification of workforce and loss of institutional memory.
This post was not intended to be “all gloom and doom”. Not many people make offshore decision just for the fun of it. Outsourcing is only one of the tools IT leadership has at its disposal today and as any tool it has its dark side. Knowing that side should help you apply the tool properly and minimize collateral damage.
And the last tip for now – if you are planning to replace some of your local underperforming workers with offshore resources get unlisted – make sure that your personal contact info is not in company directory, white pages, linkedin, resume, etc. – not a trivial task nowadays…
Using Agile with Offshore
One topic that often comes up with relationship to outsourcing software development projects is the use of agile methodologies. Having run a number of projects using agile methodologies with offshore (nearshore) partners I found that some of the classic principles do not work as well, for example XP’s “pair programming” and “moving people around” need to be taken with a grain of salt / adjusted with consideration of the lack of collocation.
Of course when it comes to agile development you need to start with agile evangelists’ take on the subject. Martin Fowler in what is now a classic article Using an Agile Software Process with Offshore Development covers 14 major lessons learned:
1. Use Continuous Integration to Avoid Integration Headaches
2. Have Each Site Send Ambassadors to the Other Sites
3. Use Contact Visits to build trust
4. Don’t Underestimate the Culture Change
5. Use wikis to contain common information
6. Use Test Scripts to Help Understand the Requirements
7. Use Regular Builds to Get Feedback on Functionality
8. Use Regular Short Status Meetings
9. Use Short Iterations
10. Use an Iteration Planning Meeting that’s Tailored for Remote Sites
11. When Moving a Code Base, Bug Fixing Makes a Good Start
12. Separate teams by functionality not activity
13. Expect to need more documents.
14. Get multiple communication modes working early
That list presents a great set of guidelines, and none of them are in the conflict with foundational principals of agile development. Some of them are unfortunately in a conflict with realities you might be facing on your project.
Let me start with items # 2 & 3. That is an absolutely correct way to improve communications – make the offshore as onshore as possible by swapping people, putting semi-permanent representatives on both sides of the ocean, etc. The problem with it is that many companies, especially smaller ones can not afford this approach. Bringing and offshore person on-site roughly brings his/her rate to what you would pay a local resource and for any considerable length of assignment is likely to cost even more than local resource. Sending your local resource offshore increases the cost substantially. Personal life of ambassadors is likely to be affected not necessarily in a positive way. To minimize the impact you might consider younger ambassadors however a lack of experience may defeat the purpose. Once again, I can not agree more with both techniques yet the chances are you would have to compromise on those and thus creating inevitable negative impact on the project.
# 4. To some degree this section plays down an obstacle that could be an agile showstopper. Martin Fowler presents a few interesting examples of cultural challenges that his team successfully overcame. You might have not as much success with it, especially when working with a third party provider rather than captive resources. Try “anti-authority attitude” with any top tier vendors in India, see how far you get – and do please let me know. Also, there is much to be said about forcing foreign culture onto people who will have to stay in the society that doesn’t support it.
There are of course many others cultural challenges that deserve a serious discussion; let me just touch on one: some people call it “having Agile in DNA”; some call it “agile aptitude”. That would be a topic for a very long discussion; for now I will cut it very short: some teams are just not made for agile; and that is a cross-cultural phenomena. The culture puts its additional imprint on the issue with deeply embedded cultural traits such as conflict avoidance, hierarchical structure, meaning of respect, etc. you often find offshore. Unless you have the luxury of building your own team you would need to asses the team’s ability to go agile and your ability to guide it thorough. In some cases you will find that being practically impossible. If ignored or not handled properly subtle sabotage will find its way to the surface through malicious compliance and will bring your project to a memorable fiasco.
# 9: Short iterations have a great positive impact on the project and alas high overhead as well which exacerbated by offshore communication challenges, time difference, logistics, etc. could be unbearable. In my experience two week iterations presented a reasonable minimum.
#12 & 13 get us into a line of fire of the holly war between agile and waterfall :) And in my opinion that is as productive discussion as the “mind over matter” (by the way the later one has been solved: “if you don’t mind it doesn’t matter”). This is not an argument anyone could ever win, there is a place for agile there is a place for waterfall, and everything in between. Pick the best tool for the job, adjust your methodology to accommodate for organizational requirements, environment and team at hand… of course “If the only tool you have is a hammer, you tend to treat everything as if it were a nail” [A. Maslow]
I think it’s enough of picking on the celebrity, time for a couple observations of my own:
Minimize the time gap. You can find many blogs and articles that talk about the time difference as an advantage, what a joke! 11.5 hrs time difference with India can easily result in 48 (business!) hours delay in resolution of urgent issues. If agile is your chosen path consider minimizing that gap; your best bet could be a nearshore offering, or farshore partners who understand the value of team overlap. Some of my favorite vendors take this issue on with a vengeance starting work hours for their employees at noon local time; interestingly enough that gives them some add on benefits such as less challenging commute.
Pick only engineers with fluent English. That one seems like a no-brainer yet you will find a lot of push against it if you deal with pretty much any geography outside India. The meaning of “all our engineers read and write technical documentation in English” translates from Vendorian (the language vendors speak) as “some of our engineers went through English boot camp when in college). While that could be a manageable obstacle for teams operating as a black box or in a well managed waterfall that will be a showstopper for a mixed team agile project.
Select developers with approximately the same skill level with exception of very few on a high and a low end; the ranking for those exceptions must be clearly understood and communicated across the team. That one cuts deep in the heart of some agile practices and beliefs so I have to put a couple thoughts here:
In software development all engineers are equal and some are more equal… The difference in productivity and quality of code for strong developer and average one could be tenfold, expecting them to work together is like expecting turbocharged Porsche and limping horse powered carriage travel together in an autobahn. If you build your team with the best and the brightest chances are they could be equal even if their experience is at different level: a bright engineer will have no problems stepping aside in a face of reason or experience. When freedom of expression is given to an average or a mediocre contributor on team that also has high quality developers the result is predictable – it’s either beat him into pulp or produce code at average or mediocre level.
There are many other negative trends that naturally develop in teams with wild mix of skill levels – cherry picking, slavery, slacking off – just to name a few. By no means I am advocating for arbitrary hierarchy though… In my experience the best agile teams are formed by like-mind professionals of approximately same level of skills gathered around a top notch technical leader.
Adding offshore spin on the requirement to keep developers at approximately the same skill level adds a huge challenge to the team building process, especially in hierarchical societies or/and organizations.
Build a team. Easier said than done, and that’s why it is my favorite craft. Building teams with offshore components elevates the complexity of the task to a completely new level. When it comes to agile development building a team from a group of people working on the same project makes all the difference; the difference so profound that it feels like magic. The good news is that you do not need to graduate from Hogwarts to be successful at building balanced teams that perform well on agile projects. OK, this topic requires much more than just a couple paragraphs or a few posts, maybe a very active stand-alone blog can give the topic the justice it deserves… For now let me just mention my formula for success :)
Establish solid project management. A dedicated PM is an absolutely critical role on an agile project of a decent size. This role becomes twice as important when the team is not collocated and another tenfold if the team spans countries. Strong s/w PMs are a very scarce commodity though. It takes solid technical knowledge, superb PM skills and personality match, considering limited pay rate and unlimited challenges – it’s no surprise they are so difficult to find. By the way, when it comes to agile projects I would take certified PMP and get him/her to learn SCRUM (or whatever the methodology is) over SCRUM master in 4 out of 5 cases. Not sure whether I am jaded or just biased. Having interviewed hundreds PM through my career that so far has been my experience.
Continuously improve the process. There are many techniques that will help you to do so, iteration retrospectives is one of the easiest ones. My teams use round table discussion approach with everyone presenting keeps and tries that are captured and tracked by the PM. Tracking is essential as even great ideas tend to get lost unless there is a driving force behind it.
And the last one for now: do not compromise on tools. Agile teams have all too common gravitation towards open source. That’s commendable yet needs to be taken with caution. More so, when it comes to development tools open source doesn’t always mean the best or even “good enough”. Some tools supported by gainfully employed professionals offer impressive value and are substantially more reliable than those supported by the community. For example my team after numerous attempts to work around some limitations of CruiseControl settled on Bamboo with notable impact on productivity. Same goes for many other tools (CI, Testing, Code Review, Wiki, etc.), so do not compromise on them, pick the best you can afford.
Well, with all those caveats and warnings you might think that agile and offshore do not mix. I would not say so, while running agile projects with distributed teams is not a trivial exercise it could be productive, efficient and a lot of fun. Given the right opportunity I would do it a heartbeat.
Once Bitten, Twice Prepared
A couple weeks ago I found myself in a typical Silicon Valley party with at least 50% of attendees from local technology start ups. Someone offered “offshore nightmares” as a discussion topic, that turned out to be a great icebreaker as everyone of us had a few of those laughs & tears stories to tell. More tears than laughs I have to say. Among the stories there were a few common threads; one of them was very close to my heart and painful experience – a practice of misrepresenting developers’ competence popular among some offshore providers.
- Joel: we selected a vendor based on results of developer phone interviews. They were very good: great technical knowledge, decent communication skills, etc. We hand-picked tech leads and key contributors and moved forward with the engagement. People we picked were assigned to the project and we were expecting them to hit the ground running. It took a little while though – contact negotiations, setting up environment, you know. To our great surprise the productivity and quality of code was far below the expectations. The vendor blamed problems on communication, quality of requirements and so on. We tried to improve on those, put an on-site coordinator to resolve the problems, but the issues did not go away. After much ado we decided to send one of our key guys to India; he happened to be one of the people involved in the initial interviews. Few days later he called me saying that none of the people we interviewed were actually involved on the project. The people working on the project had “same names” and emails but were not the people we interviewed… [NK: Frankly, that story seemed so bizarre that I would probably did not believe it if I had not known Joel for long time.]
- Vlad: When we started working with [NK: a well known top tier vendor] I received many resumes of people for the QA team we were building. Many of those 20+ page resumes. Honestly I was not at all excited to read them but that was my only window into the future team so I had to go through that recycle paper. It indeed turned out to be a waste of my time, even though it was a slightly entertaining pulp fiction – I found that the same text, not only description of the projects but personal achievements and responsibilities, was copied from resume to resume…
- Nick: A few years ago I was going through the resumes of the team I had inherited. One of them was a resume of a junior engineer that came onboard from a corp-to-corp contract-to-hire arrangement just a few months before I took over the team. The resume had a lot of relevant experience and skills. It looked like we had gotten ourselves a great deal: the gal was perfect and hugely underpaid. These were good times, employee market, and I was not about to lose her on salary basis… I talked with her and was “pleasantly” surprised to learn that she actually never saw her resume; it was produced by her employer and had nothing to do with her real skills, experience and background…
I could bore you with more stories I heard that day and examples of similar nature, but I think the point is sufficiently illustrated. Offshoring brought putting a spin on one’s career in a resume to a new level. Misrepresenting skills of resources appears to be a common practice even among rather large companies. Fortunately, dealing with this issue requires just basic diligence on you part, here are a few simple guidelines:
- Do not rely on resumes – interview your workforce.
- If possible interview face to face: go to the vendor’s site or use teleconferencing, even simple webcam + Skype would do.
- Include resume validation questions in your interview.
- Consider including tests in your interview.
- Do not take vendor suggested resource ranking for granted.
- Develop ranking criteria in collaboration with the vendor.
- Rank resources based on results of the interviews not resumes.
- If sourcing and ranking is a black box for you control the individuals’ output (metrics, design reviews, code review, etc.)
- If even control of individuals’ performance is practically impossible work at macro level holding your vendor to accountable for KPIs that should be outlined in your SLA.
I hope that the vendor(s) you work with have high standards and impeccable integrity; unfortunately, even those companies are not immune to subcontractors’ and employee fraud, so whether you have been bitten or not stay twice prepared.
Delivering Bad News
If you are running an offshore IT engagement you have faced bad news a few times by now. Not? Chances are you will soon. I am not being all gloom and doom; it’s just the nature of the beast. As a matter of fact working in IT guarantees that you will be facing bad news, offshore just expedites the matters. This post is not as much about offshore as about bad news in general –how to deliver them and how to receive.
The first thing to keep in mind whether you have to deliver bad news or are receiving them is that a bad news is like a turn in a road: it’s not the end of the road, unless you failed to make the turn.
Let’s start with delivery. Chances are that applies more to offshore providers. Internally offshore vendors face many challenges – delivery against insane deadlines, working with mediocre workforce, turn over, and so on. These issues are not much different from those most technology organizations face independently from their location. I do not often hear about over-budgeted and overstaffed projects or unusually loose timeframes. The challenges create issues, some of the issues are mishandled, and sooner or later mishandled issues materialize into a problem that becomes a bad news to be delivered to the customer.
The time of beheading bad news bears has passed yet I guess it’s deeply imbedded in our psyche. Not many of us enjoy delivering bad news, especially when it’s personal. BTW, that is an additional complication for many of the offshore providers as the ties between personal and business relationships in many of the offshore countries has been exceptionally strong for centuries and switching to “it’s just business” attitude is not an easy transformation.
To deal with a challenging transformation you need a methodology. I suggest the one I heard from my sailing buddy. He told me that every task on a boat includes three stages – Prepare, Execute, and Cleanup.
That is exactly what you should do to deliver a bad news:
Prepare. That is the most involved and the most important part of the process. The better it is executed the easier it is to deliver the news.
- Get all the facts, supporting materials, and paper trail together. Organize your materials in a manner you can quickly access what you need.
- List all questions you can anticipate and make sure you have answers and supporting materials for each.
- Pick the best individual(s) to deliver the news. Your choice should be based on many aspects of the business relationship and in particular personnel aspects such as roles, hierarchy, and personality.
- Identify potential outcomes and develop action plans for handling each one of them. You should have a proposed solution or several of them rated by your preference prior to arriving in front of your client. Few things would go worse in such situation than a “we got a problem” followed by a blank stare.
- Decide on the approach / delivery techniques. This step should be based in a large degree on the items above and the gravity of the issue.
Execute. Aim for making this step as brief and concise as it could possibly be; there more you dwell on the problem the deeper it gets.
- Deliver the news in a manner dictated by your selected technique / approach (see more notes below).
- Provide your partner with information they may need. Suggest possible solution / proposed plan.
- Define action plans and the next steps.
Cleanup. …unless you failed to make the turn… Your actions in the clean up stage are those final movements you need to exit a sharp turn gracefully.
- Send follow up note / meeting notes / action plans / next steps / etc. to the client.
- Follow through on each item of the action plan.
- Follow up with the client to keep them abreast with the recovery progress.
There are many techniques you can deploy in the execution phase. Most famous are known as Punch in a Face, Love Sandwich, and Spinning (it also has a similar, more popular yet less appealing name).
Punch in a Face, delivering bad news without any sugarcoating, despite of its “straight shooter” appeal is a very delicate technique. It should not be used with people who take things personally or emotionally. More so even cold-blooded IT executives that never take anything personal may still prefer some cushion when it comes to very hard news. If you elect this approach make sure to deliver the news in the most concise manner and quickly move on to resolution plans, action items and next steps.
Love Sandwich works well with majority of situations and audiences. The idea behind it is quite simple: in order create a Love Sandwich place the bad news between two layers of “love”. The “love” could be an indication of commitment, general positive reinforcement, good news, etc. This technique is particular successful if information in love portions of the sandwich is relevant to the bad news. It is also important to make sure that love portions outweigh the negative filling.
Spinning is a very complex technique that requires mastery of word, sharp whit, above average diplomatic skills and has dubious results. Presenting a bad news as a good news is likely to be interpreted by an intelligent person as desperate attempt to avoid responsibility. If you measure spin in degrees (180 would be an ultimate spin presenting “bad” as “good”) I would strongly recommend never going being 45 degrees – presenting some “bad” news as “not too bad” one.
One item worth in-depth discussion is “anti-techniques”, the approaches one can use to exacerbate the problem instead of softening the blow. It’s amazing how often I have seen those while working with my offshore providers. My dear distinguished bad news bears, please never do the following:
- Rush. Never hurry through the process. Rushing through the preparation will leave you vulnerable at the delivery point. Dashing through the execution stage is likely to leave client with impression that you are trying to dodge the subject. Speeding through the cleanup stage will put you back on the same track with a new bad news.
- Procrastinate. The problem will not go away and with time the bad news is likely only get worse.
- Overwhelm with excuses. As Brian Tracy put it “A disease of excusitis, inflammation of excuse making gland, is fatal for success.”
- Announce your technique. Funny enough I heard it quite a few times – “Nick, I gotta tell you: we are in deep troubles, but let me put a spin on it…” What a silly thing to say, do you expect me enjoy watching your exercise in spinning techniques? And how does it alleviate the problem I have to deal with?
- Use preemptive announcements. “Hey Nick, I have a good news and a bad news. Which one would you like to hear first?” I do not want to hear bad news to begin with. I do not want any bad news.
- Use “preparers”. A technique commonly used by snake oil sales people: “Nick, I got a very bad news… our coffeemaker’s broken.” most of the time that means that the next thing will be a “not such a bad news” like “the car you came here to buy is $5K more expensive than our ad in a paper stated”. This technique is well known and chances are it will only irritate you partner.
- Give the bad news first. If you do have a bad and a good news never, never, never give the bad news first. It will upset your partner or put him / her / them in some other irrational state. Your good news will not get enough attention. Starting on a bad note is a sure recipe for failure.
- Change your techniques in the process. Just think about how you feel or what you think about a driver that indicates that you can pass and then cuts you off, puts a right blinker on and then turns left… Besides irritating the client, changing techniques greatly convolutes the message leaving your partner with feeling that the only thing you brought to the table was a bunch of excuses.
- Lie. You can spin, omit some gory details, sugarcoat the message but deliver the facts. Unless you have absolutely no choice avoid lying to your clients. The value delivered by lies is typically transient the liability is huge and ripple effect could be devastating.
Let us switch to a short discussion of receiving a bad news. Unfortunately, that is something all of us have to deal with independently on what side of the table we are. Let’s use the same sailing technique – Prepare, Execute, and Cleanup.
Prepare. In this case “Prepare” has a very special meaning. Consider sailing a boat in strong winds; suddenly in a middle of a turn one of the shrouds (shrouds are steel cables that hold the mast up from side to side) snaps. That is a very bad news, which could mean broken mast and many other bad events to follow. The first step you need to take (and in this example immediately) is to get the control of the situation and prepare for your next steps. Get in control of the boat.
When you hear a bad news the worst thing you can do is to get emotional. Do not react – respond. You may elect to show your frustration to the partner and even appear emotional. As a matter of fact there is something to be said about doing it on purpose (consider it an exercise in Golden Rule of Haggling #6). It is through extremely important to keep your head cool. Just consider what Chesley Sullenberger had to do to ditch his plane in the Hudson River saving all 155 people on-board. Get control of the plane preparing to use remaining resources to execute a maneuver that you have never tried live. Fortunately in IT Outsourcing world our challenges typically do not put us under as much pressure and give us enough time to prepare.
Execute. Execution stage is very straightforward and may involve digesting the bad news, options, outcomes, etc. You may elect to brainstorm with your partner, or take their input and do brainstorming internally. One thing is important to consider. You do not have to make any decisions, agree on action plans, etc. right one the spot. More so it is better to do it after you had a chance to digest the news, go through what-if analysis, decide on your preferred actions and when you are not emotionally affected by the news or the presence of the partner.
Cleanup. This stage depends in a large degree on what you decided to do. It may vary from just simple follow up to termination of the engagement.
Wow, that ended-up to be a very long post and I have not even covered the most important aspect – how to minimize the probability that you have to deal with a bad news delivery. I guess I will put it in another post some time soon.
ESL Tips & Traps
In the stream of holiday mail an email from an old friend of mine stood out with its unusual greeting: “Hell Nick!” The missing “o” reminded me of many written and oral blunders I generated over the years and probably continue to without even knowing.
I arrived in the states in ‘91 with practically no knowledge of English. By the mid 90s my English skills progressed a bit; I also moved up from a back office developer to more managerial / client facing roles, so the demand on the skills quadrupled. Thanks to language tapes and a lot of time behind a steering wheel I eventually made it into the “fluent” zone. At least that’s what I thought. One day I was in a discussion with a client in a face-to-face meeting. At some point my good friend and colleague Lindsay Soergel called a quick break, she took me aside and said: “Listen Nick – it’s not “Grand Poopoo” but “Grand Poobah”. What you just did is that you called the CEO of the company Big S@#%”. Later that day over a few drinks we came up with a term “nixymoron” as a combination of “Nick” and “oxymoron”.
From that point on my team took twisted pleasure in collecting and reminding me about my idiomatic expression skills, the list of nixymorons was growing and included marvels such as:
That doesn’t fit, like square pigs in round holes!
You are such a Mister Smart Panties!
I am stuck now between the rock and a hard on!
I have been fool-time employed for over a year now.
I can’t stand him having those pissy fits.
Linda, I think this is really up your valley.
We need to rump up this customer fast!
While this is still far from saying at an exclusive black tie party “Up your bottoms!” instead of “Bottoms up!” (attributed to Mr. Michael Gorbachev) I think I could still put myself in one league with Ms. Malaprop…
Anyway, the reason for this post was to suggest a few tips on communication for those of us for whom English is a second language and still WIP. Just a few high points:
- Turn your spell checker permanently on, use grammar checker as well. That will help you to eliminate some of the most embarrassing communication blunders. I recommend using MS Word as your email editor in Outlook, enabling spellcheckers on your browsers, using similar tools on mobile devices. It won’t help you with word confusion and you might occasionally call Brian “Brain” though.
- Stay away from idiomatic expressions unless you’ve seen them in a written form and clearly understood what they mean and the connotation they deliver. Take for example one of my gaffes – calling an exclusive fund raising party a “hash-hash affair”. Or here is a classic example you might want to consider: there is a somewhat rare expression “The Hand That Rocks The Cradle” that praises motherhood as the preeminent force for change in the world. It was coined by William Ross Wallace, an American 19th century poet. This expression was used as a title of a movie and a few songs. With a certain stretch this expression could be used in a reference to a mother. There is also a story of a Japanese American businessman who was apparently in love with using idiomatic expressions and titled an obituary for his mother in a major newspaper “The Hand That Rocks The Cradle Kicked The Bucket”.
- Don’t try to translate your native language expressions into English. For some reason that’s very popular among those with mastery in their mother tongue. Believe me that “to kill two rabbits with one shot” is not at all better than “to kill two birds with one stone”. More so, phrases like “Did you just fall off the Moon?”, “Stop hanging noodles on my ears!”, “You have no face!” (these are literal translations of common Russian idioms) are not likely to reach your audience.
- Stay away from lingo, teen talk, etc. “Dude, Dis doc is totally da bomb! It’s so fresh my mamma could hang wid it…” is not the way to say “Nick, This is a very well written document. Everything is crystal clear and easy to understand.” even if you are native speaker. Coming from an offshore PM that looks completely ridiculous and instead of breaking the ice (what might could have been an intention) it may break your relationships.
- Be extremely careful with the humor. Humor is one of the most powerful elements of communications and in good hands can achieve a lot. However that is a tricky weapon which is likely to backfire if mishandled. Shooting oneself in a foot while operating that weapon in cross-cultural environment is quite likely. Same as idiomatic expressions jokes, pans, and anecdotes do not translate well. I am not saying that you should stay away from humor, just saying, be very careful unless you enjoy listening to crickets chirping.
While many of us from ESL community greatly expand the boundaries of what could be done with appropriate misuse of English the problem applies even to native speakers. That’s why you might want to look at Commonly Misused Words and Phrases or more comprehensive List of commonly misused words from Wikipedia.
And let me finish the post with a (de) motivational quote Even if you do learn to speak correct English, whom are you going to speak it to? – Clarence Darrow
Outsourcing and Email Etiquette
Nothing made a more profound impact on business communications than email, and nothing probably ever will; well, unless telepathy is adopted by the corporate world, and that is probably not going to happen during my time. So it’s not surprise that there are 100s of books and web sources covering email etiquette, rules, techniques, tips, tricks and traps. Yet, I see again and again the lack of attention to email rules and etiquette ruins business relationships, creates communication problems, and dramatically affects project communications.
Email rules and etiquette is a general issue. I see it as a local challenge and go through communication training with my in-house teams (even though it seems kind of weird coming from someone for whom English is a second language and still work in progress). The importance of email is 10 times higher when it comes to outsourcing. It is impossible to overstate its significance, especially for vendors / providers. Given that a good portion of my audience is outsourcing providers this topic is worth investing into.
Let’s start with classic DOs of professional email, or The Keepers:
- Keep it Short. I suggest keeping in mind a 10 seconds principal – write your email with expectation that the reader should spend not more than 10 seconds to read it. If you need to communicate considerable volume of information email might not be the vehicle to use. If that’s your target audience preference or some other reasons make it so put a 10 second summary upfront.
- Keep it Simple. Write to express not to impress. That is particular important when it comes to outsourcing, you Harvard vocabulary won’t help much to ESL members on the thread. Here is one of my favorite examples which takes a few seconds to comprehend even if English is the only language you speak – “Unremitting fealty to his métier sans interludes of hedonistic deflection renders Jack a hebetudinous hobbledehoy.” Just in case see “translation” in the bottom of the post.
- Keep it Personal. You should always mention recipient by name, use proper salutation and be polite.
- Keep it Formal. No matter how close you are with the recipient if you are writing a professional email you are engaged in conversation between two professionals. See a few tips on professional email etiquette below.
- Keep it Legal. Always be aware that you are talking on company behalf. In particular remember that there no such thing as email Security or Privacy. Business email sent to/from a company server belongs to the company and might be read by someone other than your intended recipient So, never put anything in email that you will not say in public
The next rule is the Brevity Principle, or the simple basic, and yet most frequently broken rule: Business email should be limited to a single topic. Sending email covering a variety of topics almost guarantees that some of those would be missed, lost or misinterpreted.
Very important rule is to stay away from clichés and limit your use of idiomatic expressions. Once in awhile you come across people who are just can not say things in a plain manner and the content of the message gets lost in a stream of expressions. “Let’s run it up the flag pole to see if it passes the acid test, or we’ll be back to square one. That ought to give us a ballpark figure beyond a shadow of a doubt what our bottom line will be. If we can’t hit the nail on the head we might have to bury the hatchet and get back to our original bread-and-butter issues.” I am still trying to figure out what this one meant.
There is more to it. Idiomatic expressions are dangerous traps in cross cultural conversations. Just a few weeks ago I was talking with a brilliant techlead of my team in Latin America. When closing the discussion I asked – “Javier, do you think we are on the same page now?”. “I am not sure Nick” – he replied – “what is the number of the page you are on?”
And now a few email etiquette rules / tips on keeping email professional:
- Reply in timely manner. I recommend using 24 (business) hour turnaround time. In case you need more time to address the issue / etc. send a brief status email.
- Answer all questions, and pre-empt further questions.
- Use the fields correctly
-
- From (make sure that your email client is setup properly)
- Subject (40 char summary of the email body)
- TO (intended receipt of the email)
- CC (keep the number very small – do not spam people just for FYI reason)
- BCC (avoid using it altogether)
- Do not shout, in particular:
-
- Do not USE ALL CAPS
- Do not use excessive punctuation – Why???????
- Do not use “teen talk”, IM lingo and other casual language – WTF!?
- Do not get “personal”, especially “in public”, never:
-
- Reprimand someone in email
- Make someone look stupid
- Question one’s credibility
- Watch your attachments
-
- Do not forget them (you may want to consider Outlook plug-in that does the attachment check)
- Do not send files that are large (over 1 MB) or likely to conflict with email rules (e.g. *.exe files)
- Do not use vCards and certification pics (they make every email appear to have an attachment)
- Be extremely careful with
-
- Humor (potentially huge communication trap in cross-cultural setting)
- Reply All
- Adding recipients to email thread
- Message threads
- Forwarding
I guess that covers high points. To see more on the topic just google “email etiquette”.
“Unremitting fealty to his métier sans interludes of hedonistic deflection renders Jack a hebetudinous hobbledehoy.” is just a fancy way of saying “All work and no play makes Jack a dull boy”
Outsourcing in the Light of Bribe Payers Index
Have someone offered you some funny smelling incentive package to close an offshoring deal? You may not be alone… I just run across an interesting article, not specific to offshore outsourcing but very relevant though. Bribe Paying Export Countries by Daniel Workman talks about some unusual stats – “The 2008 Bribe Payers Index ranks the likelihood of importers receiving illegal monetary incentives from leading export countries.“ Here are the highlights
Countries Most Likely To Offer Payola
Final results from the 2008 Transparency International survey rank export companies from Russia, China, Mexico and India as most likely to bribe.
1. Russia … 5.9 (33% more likely to bribe than Canada or Belgium)
2. China …6.5 (26.1% more likely)
3. Mexico … 6.6 (25% more likely)
4. India … 6.8 (22.5% more likely)
5. Brazil … 7.4 (15.9% more likely)
Countries Least Likely To Grant Illegal Incentives
The BPI survey ranked Canada and Belgium as home to exporting firms perceived as more ethical and therefore apt to avoid illegal payoffs.
1. Canada … 8.8
2. Belgium … 8.8
3. Switzerland … 8.7 (1.1% more likely to bribe than Canada or Belgium)
4. Netherlands … 8.7 (1.1% more likely)
5. United Kingdom … 8.6 (2.3% more likely)
See more figures and supporting material in the original article TI Report: Emerging economic giants show high levels of corporate bribery overseas.
Offshore & Sexual Harassment
What a strange topic, it feels quite weird even to bring it up. After mandatory training, posted policies, and tons of wasted energy you’d say that is a dead horse. Alas, offshore-related sexual harassment could quickly grow into a real problem if not dealt with promptly. The trap is actually right one the surface: the standards of office behavior vary greatly across the world, with US culture being one of the most restrictive. Another aspect is a different social position of women in other countries, with US being one of the most advanced.
I am not about to get into insinuations about what’s right or wrong, my only objective is to highlight a potential trap. Many outsourcing companies, even large ones, with advance cultural training and extensive experience working with US companies do not get remotely close to what’s needed to prevent actions of their associates that could be considered sexual harassment by US standards.
Not so long ago I had a large group of offshore resources working onsite as an integral part of my team. In period less than a year we had three complains related to sexual harassment that required management involvement. One was a case of “unwelcome sexual advances”, another two related to emails with vulgar jokes and graphics. One of the cases resulted in associate being fired, all three demanded great deal of effort for resolution and dealing with unhappy employees from the core team… The most surprising thing about these cases was complete ignorance of senior members of the offshore team who were supposed to deal with the incidents on the topic; that was in particular alarming that the vendor was a top tier Indian outsourcing firm.
The right and easiest approach of dealing with this trap is tackle potential issues that may arise from vendor’s ignorance in standards of business conduct far before you face an incident. While that appears to be “vendors problem” my strong recommendation is to deal with it yourself, at least control / verify how vendor deals with this issue.
If you have a group of offshore resources working onsite the easiest thing to do is to put them through corporate s/h training. If you do not have one in place you should hire professionals or run one yourself. There are plenty of materials you can find on the topic; including below is a slide deck I use for training.
Another important activity you may want to consider is educating your employees about cultural differences and standards of office conduct they may encounter with. That’s especially important if you consider sending your employees to work as a part of offshore team.
Non-hire Trap
One of the first steps in most of offshore engagements, often even before you decide on the vendor is signing non-disclosure and non-solicitation agreements. NDAs and NSAs have become so common that often they are signed without understanding a potential penalties they may lead to. Below are a few fairly common tricky situations related to non-hire clause:
- I had several situations when a developer brought to me by my offshore vendor for an on-site assignment approached me for a full time position. In every case that was a highly respected developer with in-depth knowledge of our products, etc. close to the end of their on-site assignment. In every case the developer had alternative offers and was not planning on going back to his original employer.
- I’ve seen some tricky situations when top-notch employees of companies who did not make through selection project came to us looking for full time employment when the deal did not happen.
- A few times I had to deal with the situation when a new vendor brings me resumes of the employees from the vendor that has been replaced.
There are many other scenarios with the common issue – you are interested in hiring an employee but can not do it without breaking NSA.
In many cases the non-hire situation can be addressed to both parties contentment. The typical approach I would suggest is considering hiring employee as if you were working with a recruiter. 15-30% of employee annual salary could be amount which would keep the vendor happy under certain circumstances. That has to be handled with great caution and respect to the vendor. Some companies put substantial investment in the resources on all fronts – from acquisition to training and benefits, for them 30% may not represent a sufficient amount. I find the wording non-hire clause as a great indicator. Here is for example an extract from NSA with one of very employee-focused organization:
During the term of this Agreement and for a period of two (2) years after the later of the date of this Agreement or the completion of any SOW under this Agreement, each party agrees not to, directly or indirectly, initiate employment discussions with, hire or use in any way the services of an employee or contractor of the other Party. The parties specifically agree that a material, uncured breach of this provision will entitle the non-breaching Party to agreed upon liquidated damages in the amount of two hundred thousand dollars $200,000 per occurrence with a maximum aggregate limitation of $3,000,000. Subject to the time limitation set forth in the first sentence of this paragraph 11, this provision applies to employees and contractors who are no longer employed by the Vendor or by the Client but were so employed at any time during the term of this Agreement.
You may consider he figures to be over the top, I did. However, the truth of the matter is that this particular company wants to do whatever it takes to prevent brain drain whether it’s instigated by the company or by the employee. And that’s deserves some respect and twice as much serious attention.
However, most of the time you do not find the NSA / NS clause worded with such might. Vendors understand well that in many cases they can’t do much about losing a particular employee, and losing him/her to a customer may play in very positive manner towards improving customer satisfaction / retaining the customer, etc.
Here are just a few obvious tips on dealing with non-hire trap:
- Deal with NSA with consideration that you might be facing it’s bitter end.
- Stay legal – do not solicit vendor’s employees, even they seem a prefect match, do not even give any clues or signs. If the associate comes to you that will put you in the best negotiation position with the vendor and with associate.
- When facing the “situation” stay legal in all aspects and consider the hierarchy of importance: yourself, the vendor, the associate.
- There is almost always a way to negotiate the situation with your vendor in a win-win manner. Consider “win-win or no deal” approach.
- You may not always get what you want, in particular there will be situations that you just won’t be able to get a particular employee. Let it be.
The Myth of the Onsite Coordinator
One of the proven methods to improve quality of communications with the offshore team is to have a dedicated person to coordinate and oversee its activities from your site. This person should ensure the communication flow, act as liaison between the teams, and often interpret information from local to offshore language. Even if the both sides speak English fluently (e.g. outsourcing to India) there is lot of subtle differences in business lingo that need translation. More so the person could be charged with business analyst activities interpreting domain specifics to technical language of the development team. On my book offshore manager should have very solid PM/PMO skills, in-depth understanding of the processes such as SDLC, strong knowledge of the domain, and of course understanding of the offshore. The job description for the person quickly adds up to a very tall order. Add to it logistic challenges – this person typically ends up working long odd hours – and you realize that it’s not an easy task to find some who can do it.
Of course I am not the one who invented dedicated offshore managers, as a matter of fact even for a fairly small engagement your vendors would strongly recommend that you put a full time onsite coordinator on your team. The vendor is likely to have long list of Pros for adding the person to the team, not surprising it’s a very common add-on sold pretty much with every contract.
There are a few serious caveats here, if not to say traps. Something I have observed on multiple engagements:
- Onsite coordinator could be just a slightly disguised sales executive with primary objectives that have nothing to do with real objectives of offshore manager.
- Onsite coordinator could be grossly unqualified for the job but given it due to some internal reasons – for example as a holding position between assignments.
- Most often the onsite coordinator is just that – a mere coordinator – far less than you need for the position.
Each of the scenarios above is guaranteed not to deliver on the objectives of an offshore manager and to prevent engagement failure you’ll need to invest in the manager as well, in that case why do you need coordinator?
More so, one of the biggest issues with offshore onsite coordinator is the mind set, is s/he going to have your interests at heart or interests of the company which pays him salary? When inevitable problems come up on what side s/he will be? Let’s say that problems are severe and you have to take your vendor to court, can you really count on onsite coordinator to be unbiased?
I can not tell you how many times I had this discussion with offshore vendors who continue to push for the “best practice”. Well, if that’s so helpful for you to deliver on the engagement objectives why don’t you do it on your own expense? That question typically falls on deaf ears.
When you consider expense, typically either offshore rate + per diem / hotel / car / etc. or onsite rate of ~$80 an hour you realize that it’s might cost effective to find offshore manager locally. Good offshore managers are not easy to find and they are not cheap but believe me, they are worth every penny.
Offshore Model Selection: T&M vs. Fixed Bid
It’s quite amusing to see many offshore vendors to use LinkedIn Answers for self-promotion but instead of leads generating volumes of offshore-bashing. However amid of self-advertising and political positions you can find browsing this section helpful in many aspects, no cloud without a silver lining I guess… This time LinkedIn Answers offered an interesting discussion topic with a help from Irina Semenova: When outsourcing projects offshore which model is preferable – Time and Materials or Fixed Bid? And my answer is… “It depends.”
What model is going to work for your specific engagement depends on the project goals & objectives, both parties’ org structure and experience, SDLC maturity and style, etc. The selection should be made by careful analysis of all ingredients and with consideration of classic engagement objectives: scope, time, budget, and quality. Below are some tips that you may want consider when making the decision.
If the scope of the engagement is extremely well defined and firmly set Fixed Bid model is very natural way to go. Some of my friends from Agile Camp would probably say that the scope being “extremely well defined and firmly set” is an oxymoron – requirements always change, etc. Well, I do not want to start a philosophical discussion; instead, I’d rather mention a few items that often overlooked in scoping exercises:
- Non-functional Requirements. This is not a very good term but widely used for some reason. By non-functional requirements I mean horizontal requirements that apply to the product not to its functionality. These requirements typically include dimensions such as performance, scalability, maintainability, interoperability, etc. They are extremely important for any project but often overlooked and dealt with in catch up mode exploding the cost of the engagement. For FB projects you not only must specify upfront the requirements but also defined how the compliance would be verified.
- Delivery Requirements. Sometimes considered a subset of non-functional requirements the specifics of engagement delivery affect the cost dramatically. The vendor typically has its own benchmarks in that respect which could be drastically different from your expectations. Do you expect to have 80% unit test code coverage? Do you expect well-document DB design delivered in Erwin format? All these requirements must be spelled out before FB contract is put in place.
- Communications. The volume of communication is a notable aspect in vendor’s overhead and thus affect the cost of the project. You might be expecting daily project updates and rigorous reporting at multiple levels while the vendor thinks just milestone updates and PMO quarterly meetings. It’s much better to bridge the gap up front.
- Quality. It is extremely important to specify Acceptance Criteria in all aspects of Quality of the product as well as process of Acceptance. Metrics and methodology definition should be one of the inputs to the vendor for defining FB price tag.
- Change Management. Any vendor that has meaningful experience in delivering FB engagements has Change Management well under control. What vendor could be not familiar with is your specific change rate and budget change tolerance. It takes tremendous expertise on both side of the relationship to manage Change Management and avoid scope creep wars.
If addressing items above in addition to developing meticulous definition of product requirements falls outside of your capabilities you can hire your vendor to do it for you on a Time and Material basis. That appears like a nice T&M segue into a FB model. There are a few traps associated with that model though. The main being a potential conflict of interest: Will the vendor has your best interest in heart and won’t use this exercise to dramatically increase the scope of the project? That’s not unheard of. You can mitigate that risk by hiring different vendors for FB and T&M portions of your engagement; that approach of course has its own drawbacks.
With all these complexities of FB model why even consider it? Why don’t just go with T&M for all types of engagement? Well, some projects land themselves extremely well in T&M space, for example a classic team augmentation – situations when you just need a team of QA engineers added to your organization during major release, or you need a graphical artist to assist with development website, etc. There are as well a plenty of other situations that make a short or long term T&M arrangement the most meaningful. You should not rule out a FB model for engagements of recurring nature and augmentation tasks though. For example an ongoing legacy s/w maintenance and support task appears as a great candidate for T&M, but it could be extremely well handled as FB SLA arrangement.
A popular concept states that vendors prefer T&M model because it allows them to achieve maximum utilization of resources while being shielded from customer failures to deliver on their obligations. That is a major misconception. Under true T&M model the vendor gets paid only for work being done and is not for waiting for customer to make up their mind. In majority of the situations that would mean that developers would be sitting on their hands for major portion of the project. So typically T&M engagements are sold as “minimum utilization” models, in those the customer pays the maximum of minimum agreed upon amount and T&M amount. That model shields the vendor quite well.
In that light T&M model doesn’t only shield the provider it also reduces dramatically inevitable scope creep wars on fixed bid projects. In many aspects it is good for both sides. The main challenges it presents for the buyer are somewhat hidden and thus create serious traps. Here are just a few to consider:
- Carefully constructed T&M project opens a huge opportunity for add-on sales and could generate enormous amount of unnecessary work. As proverbial car salesmen IT consultants are exceptionally skilled in upselling the customer, keeping themselves occupied, and discovering new opportunities. On the other hand buyers become their own worst enemies as T&M promotes sloppiness in handling scope. As a result T&M projects, unless handled properly, have a high probability of costing more, often much more than expected. The example which comes to mind is ERP implementation which I observed at a large automotive manufacturer; being budgeted initially at $30MM it ended up costing in excess of $300MM.
- T&M projects require meticulous time tracking which could become a considerable overhead. I remember myself spending easily 1 hour a day on keeping track of my time in three systems, of course that hour was billed to the customer as well. For developers that are not used to consulting lifestyle timetracking is true bane of existence, often resulting in malicious compliance producing little to no meaningful results.
- T&M projects are more difficult to budget for and are real pain in GL allocation when services cover multiple cost centers / etc. Appropriate allocation in particular requires detailed time tracking with its respective impact and reliability issues.
Outsourcing Impact on Technology Choice
I find LinkedIn to be a good idea generator for blog topics, for example a question from Vinay Joshi “.Net OR Java what technology projects you outsource — Does technology matter for making decision to whether outsource or not? …” deserves substantial discussion, beyond my brief answer on the site; especially considering that the rest of answers are more about religious war of .Net vs. Java rather than about the question itself.
Of course the answer depends on the context, if you are a technology company that already has the technology selected or a vendor that has a large team with specific expertise in place the discussion has little relevance. For those about to outsource it could be quite important decision though.
If you are planning on outsourcing but have not selected the technology yet, here are a few tips to consider:
- Flexibility offered by technology is not your friend. The more discipline the technology offers / requires the easier it is to control it, the less are the chances on-shore and off-shore teams drift apart. In particular using Java vs. .NET discussion – Java offers great flexibility and far less commonalities in solving even basic development task. There is always 10,000 ways to achieve the same objectives. It offers multiple schools of thought and competing technologies. .NET offers more disciplined approach, while it offers some flexibility it’s far less the focus or the modus operandi, typically in .NET there is “the right” way of dealing with majority of tasks.
- Emerging technologies are not made for outsourcing. That seems like a no-brainer, yet I’ve seen many companies moving projects using cutting edge technologies offshore, typically with painful consequences. So just in case, there are many reasons not to do so: lack of experienced resources, blind spots in understanding the technology on the both sides of the ocean, insufficient supporting community and documentation, undeveloped best practices, etc. Each of these issues by itself can destroy the engagement, when the issues combined the failure is guaranteed. Both Java and .NET by themselves are established technologies, however there is always something new being pitched by the respective camp.
- Close doors to Open Source. Well, that might be too strong of a statement. As a matter of fact I did quite well outsourcing development using Open Source technologies and products and so many people I know. Caveat emptor! If you go for Open Source make sure that you do not stray off the beaten track and stick to very stable and mature products with strong development community. Too frequent release cycle, fluctuating quality of products, unstable supporting community can add insult to injury when combined with inevitable issues of outsourcing.
- Don’t let the tail wag the dog. Some advanced technologies come with very costly or complex development tools. Some technologies require you to invest heavily in workstations or development environment. Some technologies require extremely high investment in training. And so on. Unless you have extremely compelling reason to do so, do not consider such technologies. Investing into a partner or their environment is not what you want to do especially in the early stages of the partnership. What if the partner already has it all in place? Well, do you want to be locked into using a specific partner? I don’t think so…
- You can only find free cheese in a mouse trap. In development today there are a plenty of “very simple” technologies. Those technologies could be quickly learned, and superficial or even spurious expertise sold to a naïve buyer. That usually attracts gazillions of providers and inevitably drives the price down. Have you heard about PHP freelancers for $4 an hour? Just go to elance.com or guru.com – you will find a plenty. The chances are you will get what you paid for. The main point here is while the technology at question could be extremely solid it doesn’t mean that any code monkey can operate it. Finding good providers in such technologies could be a challenging task due to the high pollution of the field. Unfortunately PHP today falls into that category, and I am certain tomorrow that will be the case with RoR.
Don’t Fall Asleep Behind the Wheel
This post is a rude reminder to all of us involved in outsourcing. Just a few weeks ago I talked about fundamental laws of outsourcing (FLO). And yet I just escaped from being hit hard by one of them, the ominous Second FLO, by the skin of my teeth. Quick note – the second FLO as the same as the second law of thermodynamic – entropy always increases. In offshore outsourcing the second FLO exhibits itself as consistent degradation of quality of services in absence of non-stop energy applied from the on-shore.
In this particular case it was about sourcing. I have an agreement with my current provider that I can interview any resources prior to them being assigned to the project and I can stop that assignment from happening solely on the results of the interview. I have to say that is a somewhat unusual agreement – most of the vendors would fight tooth and nail against it; that did not stop me on many of my contracts though.
Anyway, my vendor has been good in many respects, with quality of the resources being one of the top. So when I did not see any red flags on the resumes of a couple developers about to be assigned to the project I was ready to give the green light. I am not sure what stopped me and why I decided to interview them. But as soon as I asked for the interview all kinds of red flags stared coming up: scheduling delays, preparation phrases, language and cultural difference discussions… Making the long story short interviews were a complete disaster: the guys were not only exceptionally green, they did not have the foundations I was looking for, no grip on technology, no relevant background… they were good guys ready to learn. Sorry, but I do not pay for on-the job training…
So what happen? Why my trusted partner was about to put these spring chickens on my project? Well, just because. The second fundamental law of outsourcing is as strong as the gravity laws. You know, you can fight the laws of gravity as long as you want and yet you will end up with you face in the dirt… Uninspected deteriorates. [Dwight David Eisenhower]
Here is a metaphor for your consideration. A long time ago I was in the far north of Siberia, in Eskimo country. I saw an amazing event there – sleds led by sixpacks of reindeer were competing in a traditional race. That was indeed a fun race and a very vigorous exercise for the jockeys – they had to use a very long stick to control the deer, and make them run. Interesting thing about those deer – they do not run if you do not hit them, and, unlike horses, they would stop the second you stop hitting them. So the only way for the jockey to win the race is hit them non stop all the way to the finish line. Little did I know that many years later I would have to use the same technique on all my offshore engagements.
eBook
The Pragmatic Outsourcer series consists of 5 volumes, each covering a different phase of the outsourcing process. Volume 1: Making the Decision is available today for your free download. Volumes 2 through 5 will be available during 2010.
Read more
Tools & Links
Bidding Sites and Building Frustration
A couple weeks ago I put an RFP out for a very specific set of SEO activities on one of bidding sites. This SEO project was for my darling app – WWHOW!. Since WWHOW! is based on user generated content it offers serious SEO challenges. Having spent a few months fighting those I knew fairly well what I was looking for and did not make a secret out of my expectations. To no surprise my straightforward SEO request generated a lot of responses primarily from India-based providers. I just finished going through all responses I received to date and it looks like I will have to go through bid-response process again, maybe I have to try a new bidding site, maybe change my request format, content, layout… Frankly, I doubt that changing much on my side will affect the dynamics of the campaign and quality of responses. I might need to change the target development community…
The fact that I received not a single proposal that I could remotely go with was quite irritating. One of the reasons I was annoyed by it is its effect on my “buyer’s reputation”. In some way majority of established bidding sites penalize buyers for not accepting proposals. Some of them will even cut buyers off if they do not meet some criteria, e.g. certain percentage of project acceptance. It appears that they will cut you off independently from the reasons you do not accept the proposals. It happened to me on www.eLance.com a little while ago and since despite multiple attempts I could not reach the customer service I ended up moving to another bidding site.
Read more »
August 10, 2009 Posted by Nick Krym | Making Offshore Decision, News, Articles, Thoughts and Comments | Freelancing, Offshore Risks, Offshore Traps | No Comments Yet