1. Executive Summary
A customer contracted us to update one of their applications. Since the project was not technically challenging and involved a significant amount of repetitive effort, outsourcing was deemed to be low risk.
The
project trials outsourcing development effort to remote contractors in an
effort to better understand what is involved and when outsourcing is beneficial. To reduce development costs and maximize
profits, as well as the highly repetitive nature of the project, it was decided
that some of the development effort would be outsourced.
The following describes project details and focuses primarily
on lessons learned while working with remote contractors.2. Introduction
2.1. Objectives
The
purpose of the project was to upgrade an existing application. The application utilizes a couple of different
technologies and programming languages. The required updates were clearly defined by the client.
2.2. Approach
The approach was to outsource part of the project to contract developers
based in India. This was done as a
trial, with the desire to exploit outsourcing in future projects. The project was selected as an ideal
candidate for outsourcing because the effort and tasks were well known and low
risk.
It was decided to outsource as much of the
development as possible, while keeping any complicated development effort internal. This
was done because the design pattern for a significant amount of the effort is quite straight-forward, so it can be easily
documented, taught to contractors, and reviewed for adherence.
Other development effort was kept internal because there was a
desire to increase the knowledgebase of developers within the company, adding
to their familiarity with the development environment and applications. For the project, it was important to keep the
knowledge base and experience in-house, so specific less repetitive tasks were
not outsourced. We also wanted to keep
the more interesting and challenging work internal to benefit employees and to
ensure it was done properly.
3. Lessons Learned
There are several lessons learned from the project, including
ones specific to outsourcing effort.
3.1. Development Environment
Due to the limited overlap of business hours, it’s very easy
to waste time getting development environments working. Originally, the plan was to host a couple of
Virtual Machines (VM) locally and get the contractors to remotely access
them. This would allow us to tightly
control and monitor the development environment used by contractors, as well
has limiting their access to the end customer’s source code. However, this did not work at all. The latency that the contractors were
observing made development extremely difficult.
Typing and mouse movements were likely delayed by approximately
one-third of a second (ping www.pluggd.in).
To eliminate the latency issue, VMs were packaged and made
available to the developers. In my
opinion, remote contractors have to use local development environments for a
majority of their work to be productive.
I highly recommend using VMs to encapsulate the development
environment. If this approach is taken,
the following steps can help the process go smoothly:
- Have the VM packaged and available well before the start date of the contractors.
- Transferring it will take a significant amount of time.
- If possible, get them to transfer it over the weekend to minimize wasted hours
- Contractors should use a user with the minimum amount of permissions required
- Thoroughly test the VM remotely to ensure it will work for the contractors right away, and for the entire project. It is difficult to make changes to the VM after the fact
If a development environment is going to be provided to
contractors that they can install, provide a detailed step-by-step installation
guide, making it as simple as possible.
3.2. Productivity and Task Assignment
Initially,
assume that contractors require very specific tasks that include detailed
descriptions. Concisely specifying tasks
minimize assumptions and will ensure that they are completed as desired. Assumptions likely differ due to differences
in education, culture and project familiarity.
After a while, once becoming more comfortable with the work and
capabilities of the contractors, the level of detail required in descriptions
can probably be reduced.
Assume
that contractors will take 3-5 days to get familiar with new development
patterns. During this period, progress
will be slow. Once familiar, the
contractors will reach their full potential and productivity will peak. This is most relevant for highly repetitive
tasks.
From
experience with this project, it’s safe to assume that contractors will work
slower and will be less efficient than local resources. Without doing significant investigation into
the numbers, it’s assumed that the contractors were approximately 75% as
productive. This could be due to various
reasons such as: language barrier; no direct supervision outside of their
company; individual capabilities. An
exact number could be calculated by analyzing the estimated and actual hours of
work items for various resources tracked in Rational Team Concert (RTC).
Expect
to spend 30-60 minutes per day reviewing the work of the contractors to ensure
quality. Initially, 2-3 hours of review was
required because there was a lot of feedback required. This review time decreased to 30-60 minutes
once they became familiar with the design pattern.
RTC
was used to manage work items and as a code repository. Although RTC has tools and workflows that are
designed for reviewing and accepting developer’s code into the repository, only
the reviewing functionality was used.
The reviewing functionality allowed us to efficiently examine proposed
changes, including source code diffs and syntax highlighting. The ability to accept and reject submitted
source code changes would have been useful.
However, it was not used due to lack of familiarity with RTC.
Due to the learning curve, keeping contractors working on
similar and repetitive tasks was most efficient. Each time a work item with a different work
flow was started there was a learning curve that had to be overcome. This included the contractor being less productive,
as well as requiring more supervision, review and feedback. Expect the learning curve to be larger than
with local resources, likely due to less overlap in business hours, indirect
contact and a language barrier causing miscommunications.
Be wary whenever a new task or workflow is being performed by
contractors. Review the results
closely. The contractors tended to be
good at repeating tasks, however struggled with new tasks that required
undefined design patterns. For example,
they struggled with extending development patterns to other source code languages. Design patterns had to be
clearly defined and documented. Then,
the contractors were trained and their initial work closely monitored.
Getting the contractors to do testing and validation work
didn’t work very well. They missed some
relatively obvious defects introduced during the updates, both in the
user interface and the business logic of the application. It must be noted though, that they weren’t
pushed very hard or given a lot of time for this work. Given more time and direction, they may have
been more successful. Last, they may
have had difficulties with testing and validation work because they didn’t
fully understand the applications.
Further training would have helped with this.
3.3. Communication
The
contractors were provided with a class and methods that encapsulated most of
the changes required. This greatly simplified their training,
development workflow and effort. It also
minimized their changes, which in turn reduced the possibility of introducing
bugs, straying from the design pattern, and our source code review effort.
A
design document was also provided to the contractors, clearly detailing their aspect
of the project, development environment and their work flow. Examples of all the source code that required
updating was provided in the document. However, the design document alone was not
enough. A screen sharing session with a
Skype conference call was used to step through the workflow they were to
follow. The screen sharing session was
definitely required, and was likely more effective than the design document.
As it
is with managing any inexperienced or unfamiliar resource, it was important to frequently
follow up with them, ensure that they are working on tasks, that they were
keeping busy and hadn’t hit a roadblock.
Often roadblocks were easily solved by a second set of eyes, and
resources tended to avoid asking for help or advice and remain
unproductive. It was made clear to
contact us whenever running into issues and/or if they had nothing to work on. This was fundamental to keeping the developers
productive. Note that it is still important
to regularly check up on them because sometimes they don’t realize the problem,
or continue working without realizing they are astray.
It is
important to provide all possible contact information, and the situation to use
each communication path. Several methods
of communication were provided, including phone, Skype calling, Skype IM, email
and comments on work items in RTC. Each
has advantages and disadvantages, and it’s important to use them effectively
and for the contractors to feel that you’re easily accessible.
At
times the contractors chose the wrong method of communication. Therefore, it’s important to correct them
ASAP and clearly define the method of communication that is appropriate for
each situation or problem. For example,
adding a comment to a work item is great and highly recommended for
documentation purposes. However, if the
contractor is blocked and can’t continue working until the comment is resolved,
adding a comment to a work item is not adequate. Feedback on the comment could be delayed,
leaving the contractor waiting and unproductive. Therefore, some other form of communication
that guarantees immediate feedback should also be used.
3.4. Online Project Management Software
Online project management software is essential when working
with remote contractors. To properly
manage resources and keep them productive, documenting, assigning and queuing
tasks is required. Documenting the tasks
reduces the need for direct communication, and queuing tasks ensures there is a
backlog of work to keep resources busy.
Both are important because there is a reduced number of overlapping work
hours that allow direct communication regarding issues and new tasks. Maintaining a queue of tasks keeps developers
busy even when there is not the time to assign more work due to higher
priorities and distractions.
Repositories of tasks that include details and estimated
effort, are assigned to developers and are regularly updated also allow
managers to monitor progress and productivity on their own time without interfering
with developers. It is also a relatively
good documentation tool.
It is good practice to maintain a queue of tasks for resources
to work on so that if they hit a roadblock and others are not available to help
remove the roadblock, developers will not run out of tasks to work on. They can document the roadblock and request
help, then move onto another task while waiting for feedback. If appropriate, it also allows developers to
select tasks from a shortlist of equal priority tasks. This gives them a bit of variety and
empowerment, helping to keep them interested in the project and work when they
need a change of pace.
When using online project management software, it is
imperative that all resources involved in the project use the repository and
keep it up to date. Otherwise the
repository becomes dated and useless, and can’t be used for documentation
purposes.
The online project management software used for the project
was RTC. It was more than adequate for
the project, and provides several features that were not exploited. It was only used for source control and to
create and manage work items. Arguably,
it was overkill for the size and requirements of the project, and at times
seemed slow and cumbersome.
Some alternatives to RTC are Redmine, Trac and Trello. Redmine and Trac are both open source free
alternatives that can easily be self-hosted.
They provide the ability to manage and schedule tasks, as well as
integration into external source code repositories. Trello is a hosted solution that seems to be
well suited to Agile development. The
interface is very intuitive and easy to use, although it does lack effort
tracking, and general reporting and status features. Last, since Trello is not internally hosted,
before using it you should review their privacy statement and avoid including
sensitive information.
4. Conclusion and Recommendations
There
is a lot of potential in reducing costs by outsourcing development to remote
contractors. However, overlooking the
added management and learning curves could be costly. For the project involved, the development
outsourced was primarily focused on updating an existing application,
which involved relatively simple work flows and the development was highly
repetitive. By doing so, management,
learning curves and code reviews were minimized. The contractors were involved with a very
limited amount of development that was more technically challenging, so it’s
difficult to determine how effective outsourcing this type of development would
be.
Due
to latency issues, it should be assumed that remote contractors must develop
using local environments. The
communications latency present when contractors access remote environments is
far too great to be productive. So that
a project utilizing outsourcing starts more smoothly in the future, a complete development
environment should be created, verified, packaged and delivered to the
contractors prior to their starting date.
Development workflows and expectations should be well documented and provided
to the contractors as well. Furthermore,
these should be reviewed with each contractor via a phone or Skype call, and a screen
sharing session.
Online
project management software is a necessity due to the geographic distribution
of the project team and the limited overlap of business hours. It allows assigning tasks to developers,
creating backlogs of tasks to keep developers busy during non-overlapping
business hours, along with the ability to clearly define implementation
details. This allows managers to keep
resources tasked throughout the project.
