Wednesday, April 15, 2015

Ethics of Offshore

The ethics of using offshore resources is an enormous and complex topic.  I am not a particularly deep thinker, nor am I equipped to tackle the entire topic from all perspectives and all magnitudes.  But I will try here to address some of the ethical situations I encounter with regard to my offshore practices.

Disclosure and Refusal

Some organizations, in their desire to support local jobs and the Canadian economy, do not want to
have development done offshore.  Even though the amount of money from my projects going to offshore resources is relatively small, it is still important that the client know ahead of time and have the opportunity to refuse offshore involvement.

In cases where a client refuses offshore resourcing, I may provide a quote using all local resources (if possible), or in cases where I likely won't be able to find local resources to perform the work, I may have to decline the project.

Impacts to Cost and Schedule

When completing a project which utilizes offshore resources, transparency with regard to cost and schedule are important.  My clients understand what impact the offshore resources have on the schedule and the costs.  I don't want to set false expectations about what software development costs "normally".

When estimating a project, I prefer to do a detailed requirements gathering phase before estimating for design, development, testing and deployment.  With the requirements gathering done, I itemize all expected activities for all expected features and do a "best case", "worst case" and "likely case" estimate for each.  Depending on how much risk I think each item contains, I then choose which of my three numbers to include on the final estimate.  For the items that I intend to outsource, I estimate as though I personally were going to do the programming.  My offshore costs have to include paying multiple providers during the "trial period".  Still though, it is likely that the final costs will come in under what I've estimated for development.  This affords me three things:
  1. Funds to pay multiple providers during the "trial period".
  2. A bit of a cushion in case of resource "flake-out" and having to start over with someone new.
  3. The opportunity to be a hero when the project comes in under budget (assuming that 1 and 2 haven't used up their cushions).

Who Profits from the Cost Benefits

There are two schools of thought with regard to who should profit from the cost benefits of using offshore resources:
  1. The client is getting the same value as if all local resources were used so they should pay the same price, and I, as the service provider, can "pocket" the extra.
  2. Cost savings is one of the benefits of using me as the service provider so it is in my best interests to forward the savings to my client.
Personally, I am of the second opinion.  Because my clients are mostly small to medium-sized organizations, and many of them are volunteer-run or not-for-profit organizations, cost is a huge consideration for them.  I make money only from my own hourly efforts on the project, not from marking up the costs of my offshore resources.

Continuity, Maintenance and Warranties

One of the biggest risks that a company accepts when developing custom software is in continuity,
maintenance and warranties.  There barely exists a manager or business owner who has not been burned by a provider who flaked out on them, leaving them with an incomplete or unmaintainable software application or web site.

Continuity and the ability to provide maintenance and warranties are an integral part of the service I provide to my clients.  By retaining all the intellectual capital of my projects, utilizing offshore resources only for technical "heavy lifting" tasks, I ensure that I can offer this continuity and assure my clients that they will not be left holding an incomplete or unmaintainable product.

One deliverable I always offer clients, whether I use offshore resources or not, is a robust "Tier 3" support document.  A "Tier 3" support document (modeled after ITIL) is the technical support document that describes your technical environment and explains any specialized processing and support processes.  With the help of my offshore experts, I create a robust "Tier 3" support document that can be used by any resource to pick up where I (and my team) leave off.  After all, it's not just my team that can move on... eventually I will want to retire or move on myself, and it's important to provide clients with the information they will need to pass on to a new service provider.  

Impacts to Canadians and the Canadian Economy

This is a particularly thorny subject.  We have all witnessed the nearly complete exodus of certain jobs to offshore providers.  A prime example of this is in call center providers.  Who among us hasn't been disheartened and frustrated by the complete unavailability of Canadian representatives from a Canadian company?

As I mentioned above, I am not able to deal with the larger issues of offshore resourcing.  I am only able to explain how it works in my small world.

I am a one-woman consulting firm.  When I take on a project with a client the bulk of the work associated with that project, from project management, requirements gathering and design, to quality assurance and deployment, are performed by myself.  I use offshore resources only to fill in the gaps with some technical activities, primarily graphic design and coding.  

Many of my clients' projects would not be viable if it weren't for my strategic use of offshore resources.  Otherwise they would be faced with costs in the tens or hundreds of factors greater than by using my services or shelving their project altogether.  

Through my strategic use of supplemental offshore resources, I ensure that I keep Kraft Dinner on the table of one small Canadian business owner (ie. me), and I provide value to small Canadian organizations by helping them complete projects that otherwise would not be viable.  My clients' projects are usually so "inconsequential" in scope and budget that small multi-person consulting firms won't even entertain them.  The benefits that my clients realize from developing their software would otherwise be unrealized.


I think most of us would agree that some offshore practices involve a drop in quality (ie. call centres staffed with ESL resources.)

When I first started encountering offshore workers in the late 1990s the quality left a lot to be desired.  I was happy about that, actually.  It gave me a level of confidence that my livelihood was not in jeopardy.

Things have changed a lot since the 1990s.  The quality of programming from offshore resources has improved dramatically, even to the point where my offshore resources are certainly as good as, and often better than, local resources I've worked with.

Monday, April 6, 2015

Recruiting Offshore Provider(s)

Recruiting offshore resources can be a full-time job in itself.  Over the years, I've made some mistakes and learned a lot.  Here are some things I do to ensure the most successful recruiting.

Use Fixed Bid Projects

If my project scope is known and finite (and, for best results, my project scope is almost always known and finite) I use a fixed-bid project.  This is the best way to understand, anticipate, budget for, and control offshore resource costs.

Service providers on offshore recruiting sites such as ELance can be an individual; a robust corporation with office space, managers, and support staff; or anything in between.  In my experience, hiring a corporation is guaranteed to bloat costs without necessarily yielding additional quality or improved turn-around.  My preference is to hire individuals or very small companies.

To that end, I post a fixed bid project "budget" on the lower end of what I think the project should cost.  In general, it is the individuals and small companies who bid on projects in the lower price ranges.  The corporations bid on projects in the higher price ranges.

Set Clear Expectations

Offshore resources encounter challenges that I am less likely to deal with myself:
  1. Lack of exposure to, and understanding of, the business and the application
  2. Possible language barriers
  3. Cultural differences
  4. Limited communication opportunities

Before enlisting any offshore resources, I complete very thorough requirements gathering and design.  When creating my design documents, I:
  1. Define expected appearance and all expected behavior
  2. Define the business rules
  3. Provide wording for messages to be expressed to the user by the application (very important with ESL providers)
  4. Create screen and report mock-ups and flow diagrams to clearly communicate how the application should appear and behave.
I set expectations regarding:
  1. When deliverables are expected
  2. What time overlap window I'm seeking (ie. what hours I would like them to be available in order to overlap with my own hours online)
  3. What communication is required
  4. What my success criteria will look like

I ask my candidate to communicate their expected absences and outages (for example, festivals, holidays). 

I confirm that my candidate understands and agrees to my expectations prior to hiring them.

Prepare With a Trial Period in Mind

Whenever possible, I use an offshore resource that I have an established relationship with.  The level of trust and faith that I have when working with Robin, Sukhil, Richard, Gayathri and Chandra (cheers, all) is extremely valuable because I know that I can confidently proceed with them with a good understanding of their strengths and styles.

In cases where I have to recruit a new resource, I always hire more than one for a trial period.  There is a wide range of quality in offshore resources (as there is with local resources), and no matter how diligent I am, there's always the possibility of selecting someone who doesn't work out.

To mitigate this risk, one method that I use is to have a "trial period" build into my project plan and budget.

After I've done my thorough and complete design for the entire project, I split off a portion of the functionality - a deliverable that can be developed first, without dependency on other system features, which requires a good representation of the needed skill set.

I post a project for that one deliverable with a mention of the possibility of additional work after completion.  From the bids, I select two or three promising providers and give them all the same project/deliverable.  When selecting the providers, I try to select at least one proven provider with a solid project history and positive feedback and at least one "newbie".  The proven provider offers a level of confidence in their quality and reliability.  The newbies are often keen to start establishing a reputation in a very competitive market, so they will often charge less and deliver faster in order to get that crucial first success.

Through the trial period, I assess the professionalism, quality and turn-around of each resource.  At the end of the trial period, I pay out each provider and engage the best one for the remainder of the project.

By using a trial period like this, I dedicate one small bit of time and money to finding the right provider.  Jumping in with one favorite provider from the outset leaves me at risk of wasting time and money on a "wrong" resource and then having to start all over again with recruiting.

Short List Carefully

Depending on the nature of your project, I often receive a mountain of bids. 

I carefully review the bids, taking advantage of the tools and information ELance provides:

  1. Check the provider's portfolio, job history and feedback
  2. Review the text of their bid.  I shy away from template (spam) "we have read and understood your requirements and we're ready to begin work" responses.  I look for evidence in the bid that they have read my specific requirements and commented on specific deliverables.  Particularly good bids will include specific questions or make suggestions with regard to technology or technique.
  3. I look for the intended delivery date.
  4. I send a message to candidates I'm considering asking some clarifying questions, for example:
    1. How many people will be working on this and what is their skill/experience level?
    2. Do you have any scheduled absences (ie. festivals or holidays) between now and your posted completion date? What/when are they and what impact will they have on the schedule?
    3. Are you prepared to follow my processes with regards to communication, bug management and test system availability?
     I assess their response time and the quality of the response, and make sure they've understood and addressed my questions.
  5. I rate the proposals using the 1-5 dots on each.  For ones that I'm simply not interested in, I use the "Hide" button to move them to a separate screen. 

Closing the Loop

Using offshore resources can be very impersonal, and I often hear about resources who have had prior bad experiences of being taken advantage of, or treated poorly, or disrespected.  I try to operate with a level of respect to establish good will, even if I'm not going to be working with a resource at that time.  To that end, I close the loop with all of my applications who aren't selected by sending each a note thanking them for their bid, explaining why they weren't selected, and wishing them luck in future.