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 Piecemeal – Out-tasking
In BPO world Out-tasking has been known for quite some time. See for example
CompuPacific outsourcing whitepaper – “Outsourcing vs. Out-Tasking: Practical Advice” or an oldie but goodie - a white paper on out-tasking from CISCO. The basic idea is simple - out-tasking is typically described as farming out business processes or IT functions piecemeal rather than all at once. Examples of tasks that may be farmed out are data entry, document-based processing, such as claim handling, graphic arts development, and or document translation / localization.
Most typical definition goes as “Instead of divesting their back-office functions as a whole, companies contract out in an incremental and manageable way”. The top line benefit of out-tasking is typically stated as “out-tasking helps cut cost quickly without loss of control or high set-up costs.” The geography for out-tasking is similar to regular outsourcing with India and Philippines being far ahead of the pack.
Out-tasking could be indeed an efficient and effective way of supporting a technology organization, that if you can find a good partner, and that could be a little tricky. The issue is in volume of tasks that fall into the sweet spot of out-tasking. There are many ways of dealing with it, but first, what are good tasks to consider for out-tasking. Here are just a few to consider:
- All kind of graphical arts – need a power point presentation for a board meeting? face lift for a corp. website? helping your clients with corporate identity? Often these tasks do not justify in-house graphical arts staff.
- Creative and technical writing – press releases, web content, articles, newsletters, white papers, copywriting, editing, etc.
- Email and ad campaigns, in particular if they need to be run on ad hoc basis and do not require a lot of back and force with marketing.
- Occasional or even ongoing Search Engine Optimization activities (SEO); large spectrum of tasks here from SE submission to link building, etc.
- Usability testing. Rather controversial item, many usability exports tell you that outsourcing usability testing is doomed to fail. I do not belong to that camp though.
- Marketing materials from creative writing to brochures and campaign designs, sales and sales support materials. Outsourcing of these tasks is especially meaningful for small companies.
- Translation, internationalization, localization, etc. especially if these are once off or occasional tasks rather than ongoing activities
- Data entry of all kinds, for example transferring paper-based documents into electronic formats. BTW, these activities almost always benefit from outsourcing.
- Many types of legal tasks and services, for example developing agreements such as MSA, software licenses, terms of services, privacy policies, NDA, etc.
As you can see from the list above almost any company has a good deal of tasks that could be out-tasked. The next step is finding a vendor, or more likely vendors that can provide the services on out-tasking basis.
Finding an out-tasking partner require a different mind-set / different approach from those used when selecting an outsourcing vendor. The first rule and the main difference are to measure invest of the efforts in the search process versus the scope of task. Chances are you do not need to invest much and in case you made a mistake in selecting a partner it’s usually fairly easy to fix and find another partner.
Not that long ago we needed to build basic corporate identity for our new venture. The requirements for logo and look & feel of the site were rather ambiguous. Instead of going through the process of refining requirements we used what we had, got multiple graphical artist to bid on the project, picked half a dozen that replied first. In just a few days we had just under a hundred of logo prototypes. After a few internal meetings we picked the winner who completed the entire corp. identity package in a couple weeks. Yes, we paid a bit more that we could have but time savings alone justified it.
Similar approach could be used for many out-tasking activities. Finding providers that are eager to bid for your business is also fairly easy task, especially for things like creative writing, graphical arts, and most of the items in the list above. For example you are looking for Search Engine Optimization services. You may just google SEO services and logically those who understand anything in SEO would appear on the top of the list. Another approach could be as easy as posting a few sentences about your project under computer gigs on www.craigslist.org; make sure to stay anonymous otherwise vendor spam will be chasing you for months. Another, very efficient way is to use freelancing sites. There are a few dozens of them with very large community of individual freelancers and small to midsized companies offering the services. Most popular sites are www.odesk.com, www.elance.com, and www.guru.com. In addition to offering access to thousands of providers these site offer some value add by helping in managing vendor-provider relationship, for example offering escrow services.
Dealing with individuals and very small vendors has its pitfalls though. The rating systems provided by freelancing services are far from perfect. Continuity of services, quality of deliverables, and turn around time could be far below your expectations. I will cover some tips on dealing with it in a separate post.
If dealing with freelancers is not your cup of tee you may consider larger vendors who would be prepared to establish out-tasking relationship. There are many of those, in particular in India and Philippines. You may want to team up with a few of those on one side and with a couple of companies (buyers like yourself) on the other to provide sufficient volume of revenue stream to the vendors and meaningful pricing for yourselves.
Path toward Disposable Outsourcing: QA
Is there a better way to start a new year than writing a blog post? Of course there are plenty, but it just happens that I have one ready just in nick of time. So happy New Year, may it bring you success, prosperity, health, and happy outsourcing…
There is probably no easier way to introduce outsourcing in a software development organization than QA augmentation. Simplicity of it is actually deceiving and many companies pay high price for it. Check out my earlier post Pros and Cons of Outsourcing QA for more thoughts and tips. Despite its cons outsourcing QA remains extremely popular and thus should be considered for operation under DOM. Also in my view DOM is relatively easy to implement in QA Outsourcing engagements and thus might be considered as the best first step of embracing the DOM.
Path towards DOM in QA has many steps similar to those covered in Path toward Disposable Outsourcing: S/W Development. There are of course some subtle differences and specific steps important for Quality Assurance. Here are a few most important items:
- Strict rules on bug submission / documenting. Some of the rules are enforced by bug tracking software. Depending on the sophistication of the tool you use you may find a substantial room for creativity – which is often not a good thing. I recommend using well defined rules and templates that spell out all components of the bug report. For example the bug title has to clearly identify the issue.
How many times do we have to say that, and yet, “Problem when loading the app” keep showing up… The standards need to be spelled out, delivered to the team and rigorously enforced. One approach of dealing with problems is to a put a bug in “Feedback” or similar status and require submitter to deliver appropriate content before the bug is put in the rest of the workflow.
Considering the abundance of QA workforce being brutal could be the way to go. “First time it’s your fault, second time it’s mine, and third… well, there is no third time”. Control can be applied to every bug or less reliably on spot check basis.
- Regression and other functional test case suites should be developed at just the right level of details. Executing testing should engage testers’ brain not just fingers. That ensures quick learning of the application while maintaining knowledge. Producing large volume of testing documentation is not necessarily going to speed up transition, as a matter of fact it often rendered useless and abandoned by the new team. A simple rule of thumb is QA engineer should be able to execute existing test cases in two – three days and should be fully productive in not more than two weeks.
One of techniques that worked well in my experience is producing test cases at two levels. The first is high level that is typically linked to a single use case, the second level spells out details in a traditional test case format. This approach allows more experienced QA engineers use high level test cases and keeps them engaged, while detailed test cases provide step-by-step instruction of new team members.
- Test data must be stored in a source control system. If produced in some automatic way only the data generation scripts should reside in the source control. This is critically important. You should be able to generate entire suite of test data out of the source control system for a specific version of the application, just treat test data as part of the source code. I have to note here that this task might require some of the top developers on the team as it requires in-depth understanding of schema / object model as well as solid coding techniques.
Getting test data to that level late in the project cycle appears as a daunting task. It is however important and should be done even if it impacts schedule. Savings down the line will more than pay for immediate loses, even if you never need to execute on DOM.
Test automation combines all software development and testing techniques. Developing test harnesses, frameworks and test cases is one of the most challenging tasks in application development. Unfortunately, labeled with “QA” it rarely gets the attention it deserves.
Path toward Disposable Outsourcing: S/W Development
There are many very important aspects of SDLC related to s/w development activities which should be implemented whether you outsource or not. Some of them are essential to DOM. Your intermediary whether internal or external must verify that these steps are taken and not just as a checkmark on a SDLC compliance list, they have to be made consistently and to a degree that satisfies the intent.
The first is the code standards. Of course following language naming conventions goes without saying; there are a few more standards that have to be diligently followed:
- All names are in English (classes, variables, methods, etc.) ALL
- Sufficient level of comments, of course in proper grammatically correct English. Developers must understand that they are not required to write essays; they just have to get comments to unambiguous level.
- Same applies to headers, check in notes, etc.
Next is the documentation. Creating the documentation that could be used to learn about the code and its intent, that doesn’t lose concurrency and go stale, and that doesn’t cost you an arm and a leg is not a trivial exercise. As a matter of fact a detailed design / technical design documentation is one of the most controversial topics in s/w development methodology. In a large degree the documentation’s level of detail depends on the SDLC model employed. In particular the level of documentation details digresses considerably with level of agility of the process. That is often exacerbated by a low level of maturity of organizations electing agile methodology. I do not want to get too deep into this topic at this point, just want to point out several mandatory elements:
- High level functional and technical design documentation.
- Functional and technical design documentation at detail level, specific artifacts depend on SDLC methodology, type of the project, rate of change and many other organization specifics.
- Comments in the code written in a standard way that allow JavaDoc or similar tools to generate meaningful documentation is one of the most important steps. Same goes for DB schema.
A couple relevant notes here:
- Waterfall style processes with their high degree of details in documentation, staged delivery and isolated hand-offs work naturally with DOM, in particular when the vendor offers a higher level of CMMI maturity.
- Agile methodologies work exceptionally well DOM unless they are taken superficially. That becomes particular clear in attitude towards documentation. It’s amazing how many times I heard things like “we run agile development process, so we do not do the documentation”, never from anyone who understands agile though.
- In order to define an appropriate level of documentation for your process you need continuously evaluate value of documentation for the process and for execution on DOM vs. the cost of producing and supporting it.
Next, in no particular order some of great development practices that have been proven to work under broad range of models from clean room waterfall to XP:
- Unit Test written before the code, at best taken all the way to Test Driven Development. Take a look at www.testdriven.com a site with a lot of good references by Eric Vautier and David Vydra.
- Continues Integration. There is a plenty of info on CI and supporting tools. In CI builds I strongly recommend include smoke tests, subset of unit test suite, and a number of management reports. CI scope is typically different for check-in runs and nightly builds.
- Code Review. Somewhat controversial technique which might backfire if not performed properly; I would strongly recommend using tools to facilitate code reviews, in particular I suggest crucible.
- Frequent progress reviews with live demos; I recommend at least bi-weekly.
- Collective Code Ownership (CCO). There is however a plenty of controversy associated with this practice, in particular accountability. I see huge value in eliminating blind spots which CCO offers and recommend introducing “feature” or “area” lead. Under that model CCO still is taken to full extent when it comes to work unit allocation and yet there is a single point of contact for each “area”.
Steps towards Disposable Outsourcing
If you imagine a graph representing extended cost of outsourcing (cost that includes your out-of-pocket expenses and the internal cost associate with enabling outsourcing) over time you will see substantial spikes in the beginning and end of the relationship. Minimizing or eliminating these spikes is one of the goals of DOM, the first spike of course can not be avoided. The cost could be minimized or eliminated for the first spike on consequent engagements. There other benefits of the model related to quality of work, impact of staff turnover, and so on. DOM can be applied to many engagement models and by all means worth efforts you put in getting to it. Below are some of the best practices that help immensely in building outsourcing relationships in DOM manner.
General. These are some of the best practices which apply to outsourcing engagement independently of the content of the engagement, technology, and scope.
- Intermediary. Putting a middleman in between your company in vendor(s) offers many benefits that I covered in Disposable Outsourcing: Caveat Emptor .
- Multisourcing. The term is typically used when multiple vendors are used across engagements. The first, most important benefit of multisourcing comes from “the best tool for the job” model. A particular vendor can offer great services in .NET development while another company has expertise in localization, and another in security monitoring. In terms of DOM I recommend taking multisourcing to another level, specifically using multiple vendors for the same task, of course if the size of engagement allows. For example QA team of 20 people can be easily outsourced to two vendors.
- Cross-sourcing. I have to admit – there is no such term and I can use some ideas on how to name the following best practice. The idea is to use different vendors on different stages of SDLC, for example development is done by one vendor and QA by another. The objectives here go beyond “the best tool for the job” model aiming for vendors keeping each other honest.
- DOM Planning. You need to develop your plan for execution of DOM, in particular for engagement termination and switching vendors. Even very large initiatives and comprehensive long term engagements sometimes have to undergo drastic changes. The level of planning and complexity of organization that supports it depends on the size of the outsourcing initiative.
- Testing. I mean testing the DOM itself, verifying whether your outsourcing partner is indeed disposable. It’s impossible to overestimate the importance of testing DOM. Compare it to a Disaster Recovery planning. You may have a great plan, offsite storage of backup tapes, backup generators, etc. and yet if you never tested the process when disaster strikes that will be a disaster. The generators won’t start, the backup tapes won’t restore, etc. An example of efficient testing could be using two teams on the same engagement (see multisourcing above) and switching the teams. And that can happen to anyone. See Satyam banned from offshoring work with World Bank, and consider what World Bank had to go through.
There inherit inefficiency in each of these practices. This inefficiency is of the same nature as inefficiency of Disaster Recovery Planning. Why would someone invest in second data center, backups, etc.? Sorry for one of those “blindly dumb questions”. Just consider the expense and impact on the business a large outsourcing initiative gone sour could cause.
Methodology. There are many best practices that apply to the methodology and/or the process of product / service development which also contributes to building DOM. Using software development lifecycle (SDLC) as an example I would like to point out just a few:
- Project Management Office and many PMBOK style project management techniques
- Pragmatic approach to documentation – producing just enough of it
- Templates and style guidelines across all development artifacts, e.g. naming conventions
- Automated Build & Deploy, Continues Integration and QA Automation
- Many techniques from agile methodologies such as Test Driven Development
- Comprehensive for SDLC management such as requirements management tools
- Wiki, MS Sharepoint, and other project collaboration and knowledge management tools
This list in a large degree falls out of the scope of this blog as it relates more to building solid sustainable software development process independently from outsourcing. I will cover some of the most important elements of it in a separate post(s).
Infrastructure. Similar to the methodology above there are many best practices that apply to creating efficient infrastructure for supporting outsourced activities that also cater well to DOM. And similar to the list above it in a large degree falls out of the scope of this blog. I will cover some of the most important elements of building outsourcing infrastructure in a separate post(s).
Disposable Outsourcing: Caveat Emptor
As any other outsourcing model Disposable Outsourcing has its pros and cons and there are a few caveats worth discussing. Probably the most important one is a role of intermediary.
First, intermediary is not mandatory it is one of the best practices. There are a few tangible benefits that middleman offers here, the most important being isolation: Establishing working relationship with each vendor is a unique process, take for example MSA, the likelihood is it will be dramatically different from one vendor to another, and even if you use your own template the chances are you would have to negotiate on different clauses. There are plenty of other activities such as setting up environment, associate interviewing / screening, security, etc. that would require a significant investment. Using intermediary shields you from many of those. Isn’t it very similar to using some of well-known design patterns (adapter, façade)?
Another important reason for having the intermediary is a conflict of interests: It is unreasonable to expect that a vendor would make itself dispensable, as a matter of fact most of outsourcing companies are known for being extremely skilled in making themselves indispensable. Intermediary specifically charged with a task of enabling DOM has a responsibility and vested interest in making it happened.
There are more reasons I’ll mention just one more– intermediary is critical in supporting you through the offshore enablement and transition. These activities even with help of the third party are very challenging. In many cases that support alone justifies using a third party.
Now back to the caveat: Finding a good intermediary is absolutely critical for making DOM work and it is not at all easy. There are a few big names in the industry which play this role, in particular IBM that offers resources from smaller companies all over the world via its outsourcing wing. In a large degree it appears to be the best possible combination, unfortunately it comes with IBM price tag, as well as with many liabilities of a large company. Finding a properly sized, reliable and competent intermediary is the most significant challenge of the model.
In case you can not find a good intermediary the best approach is to build the intermediary team in-house. That could be less expensive than using 3rd party. The main challenge would be finding people with appropriate skill set, experience and knowledge. Another challenge would be setting up the group in a way that it has the authority and flexibility to do the right thing.
Another caveat of the model is a very significant challenge of creating the processes and procedures that would enable DOM. That is especially serious challenge for small to mid-sized companies and companies with low maturity of the processes in CMMI or ISO sense. I will cover the main dimensions and steps of what it mean “get it right” in a separate post. To some degree the intermediary can be a great help in this process yet still the bulk of the load falls on the customer.
One more important caveat or should I say trap associated with DOM is complacency. As I mentioned running DOM creates positive energy, has many benefits, and gets vendor to perform better. So inevitably you see the vendor as a solid partner, not someone who ever needs to be replaced… and the model starts to deteriorate: cutting corners gets more aggressive, little issues accumulate (entropy always increases), and before you know you are tethered to the vendor and eventually at their mercy. The disposability is gone along with its benefits and the only thing you have left is a higher cost of the resources that you could have got in the first place. Again, to some degree the intermediary can be a great help in preventing this from happening yet still the bulk of the load falls on you.
Disposable Outsourcing
The objective of Disposable Outsourcing Model (DOM… and it has nothing to do with XML) is minimizing risks associated with outsourced elements of the engagement. The idea is quite simple: design the engagement model in a way that the offshore partner could be quickly replaced, say in a matter of weeks, without significant impact to the engagement. Plug and play so to say.
That is of course is easier said than done. However every step towards DOM is a step towards reducing risk. DOM positioning also promotes much smoother execution of the contract, cleaner transition between phases, uneventful termination, etc. In a large degree having a DOM mind set pushes you to do a lot of things right and that positively affects your projects far beyond outsourcing components. Since the initial introduction to the concept I have been perfecting my DOM approach and finding its multiple benefits along the way.
Anyway, let me start with an example of DOM implementation in my company: About two years ago I decided to build a small QA team on DOM basis. I started with defining the objective of the project and parameters of what DOM would mean. In a few words my position was following:
- I am open to outsource ~10 FTE in QA field under Classic Augmentation model.
- I do not care where the services are coming from. As a matter of fact I am not particular interested in specifics of the companies that would provide the services.
- I do care about the quality of individual contributors and quality of service they provide.
- In case I dislike someone I want him/her to be taken of the project immediately. In case offshore team fails to deliver the quality of service I want them to be replaced in a very short time.
- I have clear understanding of rates that I am prepared to pay for these services; and I am not about to consider any early termination penalties / etc.
The list of my “wants” (just a bit longer than the list above) did not seem ridiculous – I was not planning on getting rid of anyone just because of mood swings. However, realistically speaking, there were not too many companies in the world that would accept it. So the approach was to use an intermediate party that would take the contract, would not be invested in specific resources and could shield me from all the issues I did not want to deal with. Finding such a partner turned out to be not a complex task. A few months later I negotiated and signed a contract with a company which would act as an intermediary between my team and offshore provider(s). My partner would take on the risks / liabilities of maintaining the relationship, dealing with sourcing and termination, etc.
A few weeks later I was interviewing teams in China, India, Vietnam, Uruguay, etc. A few weeks later I settled a team. And we moved on.
At this point the main challenge was building a process of making offshore team dispensable. Of course I was not planning to get rid of the team, I just had to be prepared to it and be able to execute it well. That turned out to be a fairly involved exercise as we had to make sure that everything we do with the team to get them enabled / ramped up on our product is documented. Of course we made producing the documentation an integral part of the process itself and tasked the offshore team with it. We did the same with developing test plans, all SOPs, etc. The mindset “what if this partner is no longer here tomorrow?” was pushing us to do things right. My partner’s oversight and governance was an additional enforcement mechanism – basically keeping my team and the offshore provider honest. My partner was deeply vested in getting it right as the cost of the transition would go straight out of their pocket.
Shortly after start of our initial QA DOM exercise we kicked off another team working on development project under Project-based Augmentation model.
We first realized the benefits of the approach when facing inevitable turnover and “hiring mistakes”. It was surprising how quickly we were able to add new members to the team to replace losses or poor performers.
Our biggest pay off came in when we had to replace one of the offshore teams, it was by all means a non-event. Well, far not everything went right, but comparing to my previous experiences, the difference was dramatic.
While two of our offshore teams were operating under DOM paradigm we had another two teams involved in multiple aspects of our SDLC working under similar augmentation models without DOM ingredient. That gave me some limited material for the comparison / analysis of the approach. Here are a few interesting observations characterizing our DOM experience:
- Offshore vendor was constantly on their toes; that is of course a double-edge sword; our assessment that it was much more positive than negative.
- The communications in general were better with the team working under DOM model. The number of project conflicts and issues to be resolved between onsite and offshore teams was substantially lower under DOM model.
- DOM mindset turned out to be contagious in a good sense; attention to documenting the processes and appreciation of its value went up across the team including parts of the organization that had little to do with outsourcing.
- DOM notably increased our overhead in the initial stage of the project (comparing to a regular outsourcing model); the overhead went substantially down after ~3 months. Comparing that to a regular project I would say that overhead was lower under DOM over long time.
- Attitude toward our DOM team was substantially better than towards the team operating under regular Classic Augmentation. In particular there was substantially less apprehension towards offshore team members from the onsite employees, and I would say higher sense of security.
- Interestingly enough we found that the offshore team overtime started seeing some benefits of the DOM and did not particular perceived it as making them disposable; to some degree it came down to doing things right.
There were a few things that fall in category of cons of the DOM. Here are the most significant:
- Very significant increase of the overhead during initialization of the project.
- Cost of the resources / rates are higher given other things being equal.
- Working with / through intermediary could be a real pain in the neck.
I would say the success and value of benefits that could be realized from the DOM model depends in a very high degree on the intermediary. Finding a good company to play that role is not a trivial exercise. There are a few other challenges worth discussing on the DOM and that deserves a stand alone post…
Selecting Outsourcing Engagement Model
Model selection in terms of Outsourcing Engagement Models is not a trivial process and your choice depends on large number of factors such as nature of the outsourced activities, organizational maturity, budget, risk tolerance, and so on. Below are some simple guidelines that you may consider when making the selection. See also earlier post Offshore Model Selection: T&M vs. Fixed Bid for relevant info.
Resource Augmentation / Classic Augmentation / Extended Team.
- One of the easiest ways to start with offshore outsourcing.
- Scales well both up and down (adding or taking resources off the project).
- Works well for poorly defined projects and activities.
- Requires high management overhead.
- Tends to be costly especially for not well defined activities.
- Doesn’t leverage vendor’s processes / structure / quality.
Project-based Augmentation / Task-based Augmentation.
- Good transitional model, in particular applies well for large number smaller projects.
- Scales up and down reasonably well.
- Offers good control of the scope and budget
- Offers less control over the resource productivity.
- Requires fairly high management overhead.
- Requires high maturity of the vendor processes and structure.
Project Outsourcing / Full (Activity) Outsourcing.
- Good model for well defined projects with clear scope and deliverables.
- Requires minimum management overhead.
- Well control budget (assuming well defined project and low scope creep).
- Very dangerous model for large (scope / duration) projects.
- Very high risk due to low control of productivity and performance of the resources.
- Requires exceptional maturity of both customer and the vendor.
Offshore Development Center (ODC) / Captive ODC / Captive Teams.
- Could very cost effective in terms of total cost of outsourcing.
- Offers ultimate control of the resources.
- Allows using cohesive processes across organization.
- Very high management overhead.
- Very high internal resource / cost impact.
- Requires customer to perform many operations in offshore location.
Hybrid Model.
- Inherits pluses and minuses of the underlying models.
- Some minuses could be addressed by combining model.
- The pluses of the underlying models become weaker.
Build – Operate – Transfer (BOT).
- Inherits pluses and minuses of the underlying models.
- Introduces wide spectrum of new challenges, as both vendor and the customer need to operate well in three distinct different phases with completely different models.
- Requires exceptional maturity of both vendor and the customer.
Disposable Outsourcing.
- As I mentioned in my earlier post the model falls out from the list above since it’s more like an overall approach toward outsourcing rather than just a way to structure the engagement.
- The model could be applied on a top of different models.
- Minimizes risk associated with outsourcing.
- Is more expensive than underlying models.
- Offers add-on value in many aspects of the project, e.g. reducing impact of turnover
Outsourcing Engagement Models
There are more various engagement models than it is worth listing here; some models are just naming differences invented for “market differentiation” or slight insignificant variations. In general modeling the engagement depends primarily on project delivery model, ownership of the resources, and services provided by the vendor organization on the top of the services provided by individual associates / individual contributors. This post covers the most common models using most common terminology:
Resource Augmentation / Classic Augmentation / Extended Team. Under this model the vendor supplies individual contributors who work as a part of the team on T&M basis. These resources can work onsite or offshore and typically have double reporting structure – they would report into customer organization as well into their own org structure. The vendor organization typically provides services that include HR, MIS and miscellaneous admin support. Resources maybe organized in structure groups / teams. At some point the scale of outsourcing demands more comprehensive resource management, in these cases the vendor provides project / program management and other work structure related services.
Project-based Augmentation / Task-based Augmentation. Under this model vendor supplies individual contributors who work a specific project or a task order. The work is still performed on T&M basis with addition of some elements of Fixed Bid model. In particular the vendor typically forms the team with a structure most appropriate for the project, provides program management and quality support, engages process improvement and other services that harness company resources outside of the immediate team. That additional support is typically “free” meaning that its cost is included in the team rate. The vendor is also produces upfront estimates of the work and adjusts the estimates through limited scope control process. Typically the actual cost of the project should fall in 20% range of the initial estimates with exception of the scope creep.
Project Outsourcing / Full (Activity) Outsourcing. Under this model vendor delivers a specific project or takes on a specific activity. For example it could be a turn-key delivery of the system, full scope of activities for technical support, etc. The project outsourcing typically is done on a Fixed Bid basis, activities outsourcing could be done on FB or T&M basis. Under that model the vendor takes on full responsibility for the delivery and correspondingly has the freedom to form and operate the team based on their own processes and approaches. This model can extend to full technology outsourcing and beyond.
Offshore Development Center (ODC) / Captive ODC / Captive Teams. There are multiple permutations of this model with main commonality being the ownership of the resources. In ultimate scenario the vendor provides very narrow HR, MIS and Admin services to support offshore team which for all intents and purposes works for the customer. In that case the vendor charges “management fee” based on the cost of the services, rent, utilities, etc. This model while possibly the least expensive one puts much higher burden of resource management and utilization on the customer.
Hybrid Model. As the name implies the hybrid model is a combination of models above. One of the most common implementations of the model is used for large scale initiative that start with research / analysis / estimating phase performed under one model and then continue in single or multiple streams of projects using potentially different model. For example a project can start with estimating engagement on T&B basis that produces an estimate and a project plan for the next phase which is delivered on Fixed Bid basis with scope creep handled on T&M basis.
Build – Operate – Transfer (BOT). BOT is a transitional model. It can start as any of the previous models and after a specific period of time the entire team and supporting assets are transferred to the customer. The transfer could be full scope transfer under which vendor ceases to play any role in the engagement or partial, for example transfer to Captive ODC model. The logic behind the BOT model is clear: the offshore partner can initiate operations and reach operating stability much faster than in case it is done by the customer.
Disposable Outsourcing. That is not a common term; as a matter of fact I might be the only one using it. And the model itself falls out from the list above since it’s more like an overall approach toward outsourcing rather than just a way to structure the engagement. It is however very relevant and important. The objective is clear and simple – I want to be able easily and quickly terminate a contract with my vendor and find another in case I am not happy with the vendor performance. Disposable Outsourcing is a way to structure the engagement that it could be possible, and of course it’s not at all as easy as changing cell phone carrier, there is a lot to be done to get there. I will put a separate post(s) on that topic.
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 Interviews: Personality Aspect
There are several common misconceptions about interviewing for “personality” with the offshore resources:
- It’s irrelevant. These are not employees I am hiring, why would I care about their personality?
- It’s the same as with local resources: what’s good for the home team is good for the offshore.
- I let my gut decide or I am good at reading people and I do not need any help here.
Let me start with debunking those myths:
The first one is the easiest. Of course it’s relevant; just think about how much damage a QA engineer without attention to details can do, or how much “value” a Project Manager with no appreciation for authority and processes would bring to a project.
Why isn’t it the same in that case? In some aspects it is, for example for your staff QA engineer you would be interested in someone who has great attention to details, eye for imperfections, appreciates structure and processes, doesn’t mind repetitive work, etc. All these personality traits would be great assets for your offshore QA engineer as well. The difference comes with dynamics of the employment arrangement.
Generally you can not count on keeping offshore resources on your project over two years, after that they are likely to move on; as a matter of fact for the purposes of personality casting you would be looking for just one year in offshore case; hopefully you have a better longevity with local resources, let’s say 3 years. Over that period of time some personality traits will play a role that are not as important when it comes to one year. For example you are looking at résumé of someone who changed his job once a year; that might be a showstopper for staff position but could OK for offshore resources. What about their ambitions, desire to learn new technologies, track record of continuing education, etc. Many aspects of personality become irrelevant when you are looking for offshore resources or turn to opposite.
Another important aspect of personality interviews is the team diversity. I am not talking about race, religion, etc. instead it’s a diversity of the team. I believe in diversity of personality and when building local teams I prefer to have a well balanced but diverse team. For example you need people with “big picture” view as well as “detail” view; you need process fanatics and “break all the rules” mentality. When properly cast and well balanced diverse teams perform much better than homogeneous organizations. Of course casting is a key here, e.g. you do not need a social butterfly to work nightshift processing firewall logs. When it comes to offshore team diversity could mean unnecessary complexity and unpredictability.
One more important consideration in that regard is the fact that careers of offshore resources are not in your hands. In that light again many aspects of personality become irrelevant when you are looking for offshore resources or turn to opposite.
Now, on “I let my gut decide” topic. That’s a common approach to personality interviewing not only in offshore but for staff position all across the industry. I know that some managers are just darn good at reading people and even they make mistakes. I consider myself above average in that skill, mainly because I invested great deal of effort and education in it, and yet I make mistakes, sometimes serious ones. If your gut (intuition) can pinpoint attention to details, ability to strive under pressure, appreciation for processes, impeccable integrity… or an another side dishonesty, habitual irresponsibility, lack of work ethics… well, you probably are working as FBI profiler or psychic reader 
Intuition is important and you should listen to it, no doubts about it. You just should not rely on it or just only on it when selecting members of the team, especially when working remotely, over a phone, and across the cultural differences.
Now, a really hard question: how to define personality match while interviewing offshore developers? Personality interviews are tough to begin with, offshore exacerbate the complexity of the task. The approach I typically use includes several steps:
- Simplify an ideal personality profile. For example for Black Box Tester I’d be looking only for several personality traits absence of which would be a show stopper: attention to detail, ability to handle stress, and respect for the structure / process.
- Communicate the desired profile to my vendor with a hope that the screening catches at least obvious mismatch cases.
- Prepare a few open-ended questions that cater to discovery of those specific traits. For example, “Based on your prior experience please describe a situation when you ability to handle stress helped deliver on engagement objectives”.
- Take the answers for the face value. If the candidate can fake the answer hopefully they can fake the personality trait till the time the move on to a different project.
- I usually have a few questions ready but do not necessary ask them all. Sometimes the candidate would fail a few ones just because those are unusual questions, not something they have been condition to hear. But if they can’t learn the drill after I’ve asked them a few questions, it’s not the person I’m interest in hiring anyway.
Interviewing Offshore Resources
The first set of interviews is typically performed during vendor selection stage. The goal of this interview process is not to pick members for the team; instead it is to form your opinion of the vendor capability to build a team. I typically use a speed-dating style interviewing with individual interviews limited to 20 minutes covering ~20 people a day. It is important to have at least two people involved in the interview process working together, one of the main reason for that is a continues feedback and support they can provide to each other to stay on the top of the process and increase quality of discovery.
During this speed-interviewing marathon I am not particular interested in individual performance of the team members. I do make a note of people I really like, in case if the vendor is selected these people would make good prospects for the team.
In order to prepare for the interview and perform it with decent productivity you need to go through the following steps:
- Define make up of the group you’d like to interview and communicate it to the vendor. For example:
5 Project Managers
5 Tech Leads
5 Business Analysts
10 Java Developers
5 QA Leads
5 QA Black Box Testers
5 QA Automation Engineers
For each of the position you would need to outline rough requirement s, for example Tech Lead may mean 7+ years in SW Development, 5+ years in Java, 5+ years in managing a team for 5+, etc. That list should keep you busy for a couple of days.
- Communicate to the vendor interview process, goals and objectives
- Create list of questions for each position. There are a plenty of websites offering tech interview questions and answers. I recommend creating cheat sheets with Q & A and printing them for the interview sessions.
- Keep track of interview progress with a simple spreadsheet. Below is an example of table. I use 1 – 10 rating.
| Name / Skill | Role | Exp, Yrs | PM | Lead | QA BB | QA A | SQL | Oracle | MS SQL | Java | Hbrn | Spring | J2EE |
| Ravi Krishnamurthy | TL | 8/6 | 6 | 7 | 8 | 6 | 8 | 9 | 5 | 0 | 6 | ||
| Srini Randhawa | JD | 8/6 | 6 | 3 | 5 | 5 | 0 | 0 | 3 | ||||
| Lala Caitul | QAL | 5 | 8 | 8 | 10 | 6 | |||||||
| Rajiv Shah | QA | 3 | 6 | 4 |
- Sharing the results with me vendor is a good idea, especially if the vendor is one of the winners of the race. Chances are that would be a humbling experience for the vendor.
When it comes to interviewing people for specific roles on the team during team ramp up or when replacing the team members speed-dating style is not going to produce the results you are looking for. You will need more close and personal interviewing style with substantially higher investment on both sides.
For each of the positions you will need a position description, very similar to the one you would use for captive resources, consider the following sections for the document:
- Position challenges & rewards
- Typical Duties and Responsibilities
- Required Skills, Experience and Background
- Desired Skills, Experience and Background
- Desired Personal Qualities
The document should cater to several audiences: internal, vendor and potentially the candidate. The better is the document the higher the chances of finding the right match; share as much of the details with the vendor as you can possibly gather at the point of recruitment.
Next step involves securing and organizing Interview Squad – the team that will be involved in the process of resource selection. Make sure to clearly define roles and responsibilities of the team members, communicate job requirements, outline the process, and agree on techniques.
Prepare interview questions and tests. Your materials will save you from waste of time so often common for ad hoc interviewing and will keep your team focused and productive. The questions / tests should cover the following objectives:
- Validate Skills
- Discover Talents
- Validate Experience
- Asses Personality
- Asses Abilities
During interview you will need to accomplish three basic tasks: gather information, provide information and radiate good will. It’s a common misconception that last two items apply only to full time / captive resources. In reality they are possibly even more important in offshore scenario as resources come from the same pool. If you fall short on radiating good will it is likely to backfire in later stage of the project, a mistake I made a few times and paid for dearly.
In every interview I typically highlight three components whether these are internal or external / offshore interviews:
- Set the Stage
o Courtesy questions / break the ice
o Introduce the process / agenda
o Establish expectations
o Sale on the company
o Sale on the position
- Perform
o Questions & Answers
o Tests
o Discussions
- Clean Up / Closure
o Discussion / Q & A
o Sale reinforcement
o Next steps / expectations
Questions, test and interviewing techniques are similar to those you’d use in a regular interviewing process; I won’t go in details on those here. There are a few factors that you need to keep in mind while performing the interview / evaluating results related to the offshore nature of the resources:
- Your candidates have two masters to please. That affects everything in the way they present themselves from speech patterns to content of the answers.
- Time differences / lack of clarity / procedural hurdles will work against the candidate as well.
- Remote nature of the interview work against both parties.
So the likelihood is the candidate won’t do their best and you need to account for it when evaluating results. You also should consider mitigating risk of incorrect assessment by some simple steps:
- Go there and interview your candidates face to face; if that’s cost prohibitive consider solid conferencing tools, at least webcam on both sides.
- Invest diligently in the interviewing process and ensure that your vendor buys into it.
- Make sure that the vendor does good job in sourcing the candidates and communicating the job requirements as well as promoting the good will.
- Make sure that vendor representatives are involved in the interview process and not only at administrative level. As you select team members get them involved in following interviewing activities.
- After each interview run a quick retrospective concentrating on process and candidate quality improvement.
Of course this is just a superficial overview of the subject. Interviewing in general is a very complex task, requires lifetime learning, and is one of the most important factors in managing successful offshore engagements. The good part about it is we get a plenty of chances to learn it.
Offshore Interviews: Basics
There are plenty of books, articles and various materials on the Net pertaining to technical interviewing. There are several substantial differences that need to be accounted for when dealing with offshore resources. The first one is a mindset.
Many people who outsource large scope IT initiatives outsource interviewing as well. They see sourcing (finding, interviewing, negotiating, etc.) activities as responsibility of vendor. In addition many vendors not only prefer but insist on keeping that activity internal to the vendor.
Depending on the scope of outsourcing initiative and your own bandwidth you my elect outsource the sourcing completely or to some degree. In my opinion that is the area where you need to stay involved. Quality of the resources is one of the highest risks for offshore outsourcing, and one of the factors that affects total cost of outsourcing at a very high degree. You should only outsource it if you believe that the vendor can do a very good job in sourcing, and how can you get there? – only by interviewing their resources. So interviewing is unavoidable, at least during the vendor selection process.
More so when you move into the first stage of engagement and your vendor puts together a team, how can you control the process and ensure that the team has quality resources? Amid of engagement when inevitable turnover kicks in how can you control that the quality of the resources is not going down? The uninspected deteriorates. [Dwight David Eisenhower] Only by getting involved in the interviewing.
I believe in the following interviewing schema:
- Vendor selection stage. Interview a fair sampling of resources that are “softly” committed to the engagement. The size of the sampling depends on the size of the engagement and your bandwidth. The goal of this interview process is not to pick members for the team, it is to form your opinion of the vendor capability to build a team.
- Kick off / Team Building stage. Interview all/subset of the team for the engagement. The scope of the interview depends on the size of the team and your bandwidth. For small teams, say under 20 people, “all” is the goal. For mid sized and large teams the leaders of the team and other key members must be interviewed. A fair sampling of the rest of the team must be interviewed as well.
- On-going engagement. Interview replacements for all key team members. Do a spot-check interview for new members.
And for now just a few tips on interviewing process:
- During Vendor Selection stage I typically use speed-dating style interviewing with individual interviews limited to 30 minutes covering ~20 people a day. It is important to have at least two people involved in the interview process working together, one of the main reason for that is a continues feedback and support they can provide to each other to stay on the top of the process and increase quality of discovery.
- Interviews during the Kick off / Team Building stage and ongoing engagement should be substantially more involved, especially for the key members. That typically means multiple people involved in the interview on your side, several dimension of interviewing, e.g. technical, personality fit, etc. The investment in the interview process has a very high return, however it still need to be weighed against the contract terms and the scope of engagement.
- The investment in interviewing process should be proportional to the expected value of the resources, e.g. technical lead for the project vs. black box tester. The process of selecting key members of the team deserves as much vigor and attention as if you are selecting full time employees. On a typical s/w development engagement the key members of the team include project manager, tech lead, QA lead, business analysts, and some senior engineering contributors.
The process of a full scale interview is similar to one for fulltime employees. It is easier to some degree as many non-technical issues, e.g. salary, do not need to be covered. It has its own challenges though, for example obvious issues of remote interviewing. I will cover interviewing in a separate post.
Perpetual Search vs. Status Quo
Any even a semi-decent offshore provider will tell you that they are in it for a long run. That they are not interested in “drive by” project and want to build lasting mutually beneficial relationship. That they know that you have options in the market place and they will do the best never to give you a reason to look for these options… but is it ever a “happy ever after”?
Mr. Buyer, should you ever look back and consider other options in the market place after you found a provider, went through the ordeal of ramping up the engagement and finally started getting the value from the vendor? Chances are you should.
Ms. Provider, be aware – no matter how good your services are there are stronger / better / cheaper vendors out there and their sales force is talking with your customers. Better is the enemy of good. Voltaire. There are plenty of examples when large outsourcing contracts migrate from one provider to another. That’s true for every industry, not only outsourcing.
From the buyer’s perspective there are several main reasons to search for outsourcing options outside of the current provider:
- If the provider is failing in some major way – one does not need any other reasons. As a matter of fact there are practically no reasons to stay with that provider.
- If the provider is doing well in all aspects of the engagement and there is absolutely nothing wrong with them… Brush up on Murphy’s laws: the chances are you are missing something. I am being serious, in my 15+ years of experience in offshore I have never seen a situation where there were “absolutely” no problems with my suppliers. And if you know a vendor that can do it please send them my way!
- If the provider is doing generally well in most aspects of the engagement and just causing you a few minor pains – you still should. However, before I cover some of the reasons I have to mention a few very important caveats:
- Nobody is perfect. Switching vendors may resolve the issues you are having with your current provider, it will open a whole set of new ones.
- Search for the suppliers is a cost of its own.
- Thee cost associated with switching providers is potentially fairly high. It must be considered in what if analysis for the switch.
Now just a few reasons for considering options even though your current situation is almost perfect:
- Keeping the vendor on their toes. Not just for the shier pleasure of it. It’s all about raising the bar and driving towards higher productivity, stronger value add, better customer service, etc.
- Planning for the worst case scenario or just being ready for typical issues such as key employee loss.
- Being aware of market value of the services and thus keeping the price you pay for the service in line with the market.
There is also more to be said about multisourcing (using multiple suppliers), applying “the best tools for the job” model and cross validation techniques, as well as many other related techniques that could help buyers to dramatically increase value they receive from outsourcing partner.
Offshore Payment Models
Needless to say that payments and payment models are some of the most important aspects of an outsourcing contract. While these items typically well understood and relate well to similar terms in any other consulting contracts they still require extreme attention and caution especially considering caveats off the offshore outsourcing.
The payment models in offshore contracts derived from the underlying contact execution models with most popular being Time & Material and Fixed Bid, see Offshore Model Selection: T&M vs. Fixed Bid.
Time & Material model typically translates to a payment per hour model. The rates / payment approach could be defined at a coarser granularity (e.g. week or month) but the nature of the payment methodology remains the same. If the hourly rate is used the vendor submits invoices with agreed upon frequency (most typical is monthly, small vendors often ask for bi-weekly or even weekly payment schedule). The invoice or its supporting material include hours of allocation for each resource for the corresponding period, rate and totals.
There are a few elements related to that pricing model, most important being a concept of minimum allocation. Minimum allocation defines the minimum number of hours in a month that a resource supposed to be engaged independently of buyer’s induced failures in work allocation.
You need to be careful in analysis of the associated contract language as a minimum allocation could become extremely costly.
Another set of contract elements highly relevant to hourly payment schedules is similar to minimum allocation and is related to work allocation / assignments. If a developer is waiting for business requirements clarifications from the buyer and is not engaged in any meaningful activities, who is paying for his/her time? The fair approach is for the buyer to pay for this time and for the vendor to make reasonable business efforts to keep developer productively engaged on project related activities. Make sure to have corresponding language in your contract.
One of the most popular forms of coarse granularity time based models is one often referred as an FTE model; here FTE stands for a “full time equivalent”. Under that model the rate is most typically negotiated on a per month basis. There are a few issues associated with that model that basically bringing it back to the hourly model. The first question is the workload allocation for the month with most typical number being 168 hours. The next set of issues comes from dealing with overtime, handling time off, vacations, holiday, etc. All these elements need to be understood and agreed upon by both parties.
My approach to negotiating FTE contracts is typically based around following mind set – “It is my responsibility to provide you with workload of 168 hours a month, if the employee can not be allocated for that number of hours the rate must be proportionally reduced. I also expect you to do your best to keep the employee meaningfully engaged in case I hit any obstacle or experience delays.”
Fixed Bid engagement models require a different approach for invoicing / payments. For FB engagement of a project nature the most common methodology is Milestone Payments. The idea is fairly simple – the cost of the project is divided in portions that to some degree correspond to the effort for delivery of a specific milestone. If the milestones are separated by substantial time some additional, often artificial, milestone are inserted in the project schedule to accommodate for smoother cash flow. The most important item to consider when following Milestone model is the process of had-over and acceptance of the milestones. The most frequent payment issues associated failures on FB projects related to small problems that pass through accumulate and accumulate towards the final milestone.
There are multiple variations in payment models that based on one or a combination of the models above. A few are worth mentioning:
- “Prepayment” a form of milestone payment associated with initiation of project. It is most frequently used by small vendors who can not afford the risk and expense of ramping the project up. I personally prefer to avoid prepayments. It doesn’t mean that you should exclude vendors asking for prepayment, it only means the some additional work in contract negotiation is required, for example if the resource / environment ramp up is the reason for prepayment, it could be shape as a milestone. In other cases an escrow could be considered to avoid some of the obvious risks of prepayment.
- Time-based (e.g. monthly) installments on FB contracts. I strongly recommend against that approach. In my view it really increases inherit risks of FB model. There are some meaningful situations where monthly payment associated with FB contract; that in particular common for non-project FB engagement, e.g. provision of services under SLA.
- “Bonuses and Penalties.” This is an interesting concept which could be productively applied in FB contracts for example for delivering before / after specific deadline. The concept must be dealt with a great caution though, it could become a wrong motivator and promote bad practices. Thus one of the mandatory conditions is for the vendor to receive a bonus all aspects of the delivery must be considered / met. Another important aspect to consider is the size of the bonus (as a percentage of the overall payment amount). If the size of the bonus is too small it stops making any difference if it’s too big it could ruin the project – just consider the situation when the vendor realizes in mid of the project that there is no way the deadline could be met and a huge penalty is inevitable.
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.
Downfall Impact: Do you keep your current provider?
Another good question posed by Michael Grebennikov in LinkedIn, when the market is down, the budgets tight and future is more uncertain than usual, what do you do with your outsourced projects? Of course this question can not be dealt with in insulation. Major market events require immediate and aggressive action, all aspects of the technology organization need to be dealt with quickly and in the most judicious manner. The organizations that do not react / change fast enough pay huge penalty. When Cash is getting low and/or P&L is looking grim organization must rationalize its R&D and Project portfolio. On my book that means spreadsheets, metrics, analysis and often concrete and resolute actions. The goal is to quickly reassess what you can still afford to keep and what must go, in all aspects of the organization: projects, initiatives, providers, and sorry to say staff.
The “to keep or not keep” question must be applied to an outsourced portion of your project portfolio. If the projects are not “keepers” there is no other question, if they are the question is whether to continue with the outsourcing… One of the way to answer that question is go back to the decision criteria you used when dealing with the “to outsource or not to” question. Reassessing the answer with the new environment in mind on a project by project basis could be one of the most reliable methodologies. It could be quite laborious though. You may consider a simplified set of criteria based on a few key dimensions:
- Total Cost of Outsourcing (TCO) / Price performance
- Relative Productivity
- Quality of deliverables
- Overhead / cost to manage relationship
- Quality of relationship
- Cost of termination / suspending the partnership
- Cost of restart (with current or alternative provider)
Rating against these criteria will quickly point out suspects for termination. For remaining projects / partners you can do an in-depth what-if analysis compare status quo to an alternative approach and finally make the decision.
In some cases you will still find yourself on a fence. You are still in a grey zone if your pros / cons balance is 40/60 or narrower. In that case I would consider getting the vendor involved – assuming that your relationship with them allows. The vendor has a lot of leverage in reducing the TCO and thus pushing the odds in their favor. In ideal case – and I have been fortunate enough see those – you can work out something with the partner on a basis.
The bottom line is clear: desperate times call for desperate measures. Not recognizing it on any side of the vendor-consumer relationship is lethal for the relationship
CIO.com Perspective on Offshore Risk Management
A very good article on CIO.com - Offshore Outsourcing: A Risk Management Perspective. It offers a high level perspective on risks of offshore outsourcing with specific look into several dimensions -
The article also gives some high level approach to risk mitigation. These risks as well as methods of dealing with those are most relevant to large outsourcing contracts and companies but should be considered even by small companies which in some cases could slide in between the items of that caliber.
November 13, 2008 Posted by Nick Krym | Managing Offshore Engagements, News, Articles, Thoughts and Comments | Offshore Risks, Outsourcing | No Comments