Developing BI Projects Across Time Zones and Borders

Developing BI Projects Across Time Zones and Borders
Developing BI Projects
Across Time Zones
and Borders
Frequently Asked Questions (FAQ) | February 2010
Table of Contents
Introduction -------------------------------------------------------------------
1
Making the case for distributed development -----------------------
2
Organizational and management issues -------------------------------
9
How does it all work? ------------------------------------------------------- 11
How do I get started? ------------------------------------------------------- 16
Introduction
Lower costs, accelerated development cycles and access to high quality, skilled resources are
just some of the reasons that organizations are using geographically distributed teams to
develop their business intelligence (BI) applications. In this development model project tasks
are assigned to the resources best able to complete the task, at the lowest cost, regardless
of location. Significant portions of the work are performed in low cost offshore development
centers, resulting in dramatic increases in BI project ROI.
This opportunity to maximize ROI also presents a set of risks and challenges that are unique.
Communicating requirements across time zones, coordinating tasks conducted in multiple
geographies, and recruiting, hiring and training skilled BI consultants remotely are all challenges
that need to be met and overcome.
However though the practice of using distributed teams to develop and support BI projects
is accelerating, few service vendors understand both distributed development and the specific
nuances of BI development. BI development is different than traditional software development,
as it requires closer communication with business users, and more frequent iteration. It is
important that a services vendor deliver processes and skills that are specially designed for
distributed BI development. Only then can the benefits for be realized.
1
Making the case for distributed development
What will my organization gain from using a geographically distributed team for our business
intelligence projects?
At its heart is a very simple proposition that allows you to distribute your BI development
between onsite and offshore locations so that you can take advantage of large differences
in labor costs. Lower costs however do not mean that you have to settle for lesser skills.
Frequently, offshore skills and processes are at a higher level than their onshore counterparts.
Benefits also include:
Flexibility – The resource requirements for a typical BI project begins with a small number
during the requirements and design phase, expands during development, and then declines
as the project moves to production. During each phase specialists are required in data
integration, database and analytical tools. Offshore resources provide you with the flexibility
to adjust resources during each phase, and access to specialized skills at a lower cost. Short
term projects and proof of concepts (POCs) benefit from this flexibility as well.
Quality of Services – With highly educated professionals and world-class processes offshore
development shops often exceed the capabilities of onsite shops. The client gets access not
only to the highly skilled resources on the project but also to the offshore vendor’s shared
knowledge pool and experts. A measure of the level of process maturity of offshore locations
is the Capability Maturity Model (CMM) achievement level in India. 37 of the world’s 50
“Level 5” CMM companies are based in India.
Accelerated development cycle - Differences in time zones and locations do add organizational
and communications complexity, however if properly managed, projects gain from an extended,
nearly 24-hour work day. In a typical 24-hour cycle scenario, an onsite BI project manager
will spend the first few hours of his morning reviewing BI reports developed by an Indiabased team. The offshore team would be available for a few hours to receive the project
manager’s input. Once the Indian team has finished its work day, the project manager could
draft additional reporting requirements which would then be worked on overnight in India,
for review the next day.
2
What are the cost savings I can expect to achieve?
The primary benefit of a well managed onsite/offshore DW/BI project is an overall savings
in cost, ranging from 35% to 45%. For illustration, let’s consider a typical departmental BI
project, requiring one Project Manager/Business Analyst, one experienced Technical Architect
and three experienced BI developers. We further assume that:
1. All positions are contracted. Comparisons between hired employees onsite and a dedicated
“captive” center offshore would produce similar results.
2. The project’s duration is six months.
3. The onshore Project Manager’s rate is $170 per hour. The project manager works 40
hours per week when all the work is done onshore and 25 hours per week when the
distributed model is used.
4. The Technical Architect’s rate is $150 per hour.
5. An onsite BI Developer’s rate is $100 per hour. Three developers are required.
6. An offshore BI Developer’s rate is $30 per hour.
7. The offshore Project Manager’s rate is $40 per hour.
8. All hourly rates include all travel and related expenses.
The table below provides an analysis of the potential savings:
Distributed
Role
Onsite cost
Onsite cost
Project Manager/ BA
$ 176,800
$ 110,500
Technical Architect
$ 156,000
$ 156,000
BI Developers (3)
$ 312,000
$0
Project Manager offshore
Total Costs
3
Offshore cost
(India)
Savings $
%
$ 253,500
39.3%
$ 93,600
$ 31,200
$ 644,800
$ 391,300
What are some of the challenges and risks with offshore BI development that I should be
aware of?
Offshore BI development does present a set of risks and challenges that need to be effectively
managed. First and foremost, the organization needs to determine whether or not it is ready
for distributed development and what it hopes to accomplish from the initiative. Is the DW
project under consideration even appropriate for an onsite/offshore model? Does the
initiative have a strong sponsor, and is he/she committed to making the initiative a success?
Though all projects have associated risks and challenges, there are ones that are more
prominent in onsite/offshore development. These are presented below under three categories:
Provider related risks, Process related risks and Communications related risks.
Provider related risks – As with any initiative to select a vendor to provide a set of services,
selection of an onsite/offshore vendor must be in alignment with the business’ objectives
and requirements. Paramount for offshore development:
Trust & Chemistry – In a distributed model, where many in the team will be working
remotely, you must be able to trust that your provider is operating in your best
interests. It is also important for you to judge whether the offshore team has the
right “chemistry” to work with other team members. An initial kickoff visit by either
the client or the offshore vendor team member goes a long way in establishing trust
& chemistry
Setting of expectations – Many projects fail when one party doesn’t communicate,
and the other doesn’t understand what is expected of them. With distributed
development, it is absolutely critical for both parties to understand what the other
party expects upfront, before beginning any engagement. There must be specificity
about the performance, cost and capacity of the provider to provide the services
desired. Three basic questions need to be answered:
4
•
What role will the vendor play?
•
What role will your organization play?
•
How will they work together?
Required skills, availability, roles and responsibilities – Though offshore locations
like India generally offer highly qualified resources, these resources may not be the
most appropriate for your project. Specialized skills are especially difficult to find.
A related concern is the high turnover of qualified resources in some of the major
offshore locales.
Infrastructure & Security – Most reputable offshore providers are located in software
technology parks that provide high speed internet access, 24x7 power back-up, security
and redundant systems. Included in your due diligence should be a review of the
provider’s security policies and practices to ensure that your data, information and
business practices will be kept confidential.
Process related risks – Given the time zone and geographic differences, the processes you
follow are especially important for offshore BI development.
BI/DW development processes – Business intelligence application development is a
highly iterative process requiring frequent, close interaction between business users
and the technical team. Differences in time zones and locations can make this iteration
difficult. Accurate, complete documentation and frequent communication is crucial.
Frequent, defined checkpoints need to be set to ensure that the project’s objectives
are being achieved.
Mismatch of processes – This can occur either because the organization is accustomed
to more traditional SDLC development (as opposed to iterative BI development) or
uses accelerated methodologies such as agile programming. In either case, it is
important that the processes that the offshore team follows complements and mirrors
the processes followed by the onshore team. Also be aware of differences in process
maturity (e.g. CMM 5 vs. no CMM).
Poor governance and quality assurance – Too often “out of sight” becomes “out of
mind”. Project sponsors and managers assign tasks to offshore resources and expect
that the offshore resources will be able to operate as if they are co-located. Offshore
development does add additional governance overhead. This needs to be accounted
for.
5
Knowledge transfer management – Given the remote location of the development
resources, knowledge transfer has a high likelihood of being encumbered. Specific
procedures must be in place to ensure that the information is adequately documented
and communicated.
Communications related risks – Numerous studies have revealed that the number one
cause of project failures in general is due to communication mishaps. Offshore development
is no different.
No communications planning – A plan that includes holiday schedules, frequent
meetings, communications methods (voice calls, IM, etc) and reporting needs to be
in place. For BI projects, there must be a minimum overlap of two hours between
the schedules of onsite and offshore teams to ensure that there is adequate time for
live discussion.
Language, culture and business practices differences – Though English is a primary
language and widely spoken in offshore hotspots like India, differences do remain in
style and in decision making context. In some cultures, including India, questioning
authority is considered disrespectful. This “respect for authority” can lead to offshore
teams working directly from provided specifications even if a more optimum method
is known. Plan for an initial warm up period at the beginning of any project to allow
all team members to become comfortable with each others styles and practices. Try
not to begin projects with complex tasks.
Financial considerations – Overall project costs need to include additional budget for
communications, network security and other related infrastructure costs including costs
for project management tools. Other costs often missed include the additional project
overhead to manage offshore resources.
6
What factors are critical when considering use of distributed teams for business intelligence
projects?
Research and experience in using distributed teams for BI development has revealed at least
seven factors that are critical to success. The following (some of which have been expanded
upon in other sections) would make anyone’s top list of critical success factors:
1. Risk Mitigation – Some practioners argue that managing distributed development is all
about mitigating risk. Any plan should focus on de-escalating major risks to moderate or
minor risks. The risk mitigation plan should be documented and should either reduce the
impact of potential risks, or the likelihood of occurrence.
2. Project Planning and Management – Classic project planning and management practices,
whether based on the Project Management Institute (PMI) or other frameworks is crucial.
Project management needs to consider that distributed development sets off potentially
disruptive forces that need to be balanced with constructive ones. For example, geographic
dispersion and potential communication breakdowns can be balanced with collaborative
technologies (online interactive whiteboards, instant messengers, video-conferences, etc).
BI development specifically requires that sufficient time and resources be devoted to helping
the offshore team understand the business, its requirements, and how the logical and physical
data models support the project. The goal should be to make the offshore team self-sufficient.
The offshore team should also be given complete access to the development environment,
or consideration should be given to setting up a parallel development environment offshore.
3. Communication – The pitfalls of shoddy communication are noted earlier in this FAQ.
For BI, where iteration between the business and IT is critical, one can rarely over communicate.
4. Provider – The service provider’s depth of experience, both in the chosen technologies
as well as in distributed delivery will factor greatly in the project’s success. Numerous
onsite/offshore services organizations are qualified to do traditional software development,
however very few have the necessary specialized experience in both BI and distributed
development.
7
5. Cultural Mismatch – Noted earlier in this FAQ. Especially for organizations new to offshore
development, plan time to get everyone accustomed to working with individuals from other
cultures.
6. Organization Readiness - Not every organization and every BI project is suited for distributed
development. Take the time to assess your organization’s readiness. Some specific questions
you may want to ask:
•
What is the organization trying to accomplish with offshore BI development?
•
Are the projects understood well enough for offshore delivery?
•
Do key individuals in the organization understand the risks and benefits of offshore
BI development?
•
Do project managers have the necessary skills, attitudes and experience to
successfully implement the program?
•
Are the skills for requirements gathering, analysis and design readily available
to support the initiative?
•
Is the computing and communications infrastructure suited to offshore BI
development?
7. Change Management – Even for the most mature organization, distributed development
presents changes to “our usual way” that need to be addressed. Follow change management
best practices to manage resistance and the natural human tendency to avoid change.
What types of business intelligence projects are more suited to distributed development?
As described elsewhere in this FAQ, distributed development for BI projects presents a set
of challenges an organization must be ready and able to manage, to benefit from theopportunity.
If well managed, most business intelligence projects can be developed via a distributed
model. Suitability of specific projects largely lies in the specifics characteristics of the company
choosing to deploy the model.
Generally however, corporate requirements for confidentiality of data can dictate which projects are suitable. There is obviously more sensitivity to customer and employee data than
to product data and/or sales data. Even this requirement however can be managed through
8
masking of data, or the use of sample data. This does add additional overhead, however for
larger projects the overhead may be worth it.
The complexity of the BI project must also be considered. More complex projects will likely
be less suited when new to distributed development. Consider the following decision criteria:
How many data sources are involved? How complex are the business rules and the necessary
transformations? How complex is the business – and the data model that represents it?
How much iteration will be required between the business users and the developers? Will
the reports be complex and difficult to document and explain? And, what level of customization
is planned for the user interface?
Organizational and management issues
How do I judge the infrastructure of my potential provider’s offshore facilities (i.e. physical,
computing, people, etc)? How do I evaluate the skills, experience and quality of my potential
provider’s offshore team?
Largely, one has to either work with a trusted provider, or conduct extensive due diligence.
For many projects, a trip to the service provider’s offshore location is absolutely necessary.
During the trip ask about the quality of infrastructure, disaster recovery procedures and talk
to the personnel responsible. Take the time to meet and interview those that will be potentially
working on your projects. What level of BI skills and experience do they have? How long
have they been with the company? Attrition is a big problem in offshore locations such as
India. Note what measures the provider is taking to stop attrition.
How do I evaluate my potential provider’s security policies? How can I make sure that the
confidentiality my data will not be compromised?
A security review consisting of a thorough examination of the provider’s security policies
might be necessary. It should also analyze the procedures in place to implement the policies
and it should assess how well the policy and procedures are actually implemented. For many
projects, a trip to the service provider’s offshore location is advisable. During the trip, ask
the hard questions, such as how data confidentiality is protected, and then ask to see how
9
the practice is implemented. What does the vendor have in place for securing the network
from external threats? You may consider creating a special offshore/development segment
of your network allowing your offshore engineers to work, while not providing access to the
rest of your internal systems.
Taking precautionary steps such as information, , using customer identification numbers
instead of Social Security numbers and the like will not only reduce your risk exposure, but
may also protect your company from regulatory oversight as well.
Finally consider that despite some high profile cases, data is no more likely to be compromised
in an offshore location than in an onshore (within the company) location. Regardless, you
need to ask the provider what processes have been instituted to secure data. Compliance
to standards such as the ISO/IEC 27002 is a good way to judge this as well.
How do I manage projects where team members may be located in multiple locations,
across multiple time zones?
First of all, do plan for some added overhead in managing the multiple interfaces between
locations and distributed project personnel. Technology has greatly enabled remote
management with collaborative tools (e.g. IM, VOIP etc), as previously outlined in this FAQ.
Some basic DOs and DON’Ts to think about:
DO:
•
Discuss and agree upon communication methods to the last detail.
•
Create templates for communicating (Report Design, ETL Design, etc).
•
Plan for formal written handoffs and overlap as work days begin and end in
different time zones.
•
Have continuity in key positions.
•
Conduct formal training during the project kickoff and refresh as needed.
•
Understand cultural, communication and work-ethic nuances of the offshore team.
•
Accommodate different communication styles by communicating the same
information in multiple modes (i.e. structured documents and emails, voice chat,
IM, video, etc).
•
Encourage “personal” communications between onshore and offshore teams to
the extent possible.
10
•
Provide 24 by 7 technical support for the VPN and development servers.
DON’T:
•
Think “Out of sight, Out of mind”
•
Micromanage the offshore team
How does it all work?
How would resources be deployed between my work sites and my offshore provider’s
locations for a typical business intelligence project? What work is done onsite and which
offshore?
As can be expected, those activities that require proximity to business users are the ones
that are performed onsite. Requirements gathering, architecture and design activities at the
beginning of a development cycle, and implementation at the end of the cycle are all activities
that are mostly conducted onsite (with some offshore support). On the other hand, core
development and testing activities, based on well communicated ETL or report specifications
are all conducted offshore. Following is a rough guideline on the proportion of work that
can be performed offshore, by phase:
Phase
Business Requirements
11
% Offshore
0%
Architect
30%
Design
50%
Develop
90%
Test
90%
Deploy
10%
The onsite/offshore distribution of the resources needed to work on these tasks for a business
intelligence project is dependent on the size of the project, its complexity, the level of
specificity in the requirements and the duration of the project. Generally though, the following
distribution of roles is found:
Onshore Roles
Offshore Roles
End Users
Project Manager
Business Project Lead
Data Modeler
Business Sponsors
DBA
Technical Project Manager
BI App Developer
BI Designer
ETL Designer/Developer
Business Analyst
QA Analyst
DW Educator
12
How does distributed development work for a typical business intelligence project?
Let’s assume that the decision to use a distributed model to develop your BI project has been
made, and all the necessary due diligence, planning and organization described elsewhere
in this FAQ has been done and the project has been kicked off to great fanfare. Now what?
Here’s one scenario for how it would work on a day to day basis:
Scenario
The onsite team for this onsite/offshore project for a medium-sized business intelligence
project consists of a ½ FTE Project Lead, Technical Architect and Business Analyst. The
offshore, India-based team consists of a Project Manager, two BI developers and one ETL
developer. The entire development environment is in the US, setup in a sub-network within
the company’s main network. The India-based team accesses the development environment
using a secure SSL based VPN.
For simplicity of illustration, the example below uses one BI report as the primary development
task.
EST
13
Indian Standard
Time (IST)
Activity
8AM
6:30PM
Conference call with onsite and offshore team to discuss requirements for new reports.
The US PM and the Business Analyst lead the call, using a web session to display and
discuss the requirements. The India team, having previously reviewed the written
requirements posted on the project portal, asks questions to further clarify the
requirements.
10AM
8:30PM
Indian team checks in with US Project Manager to ensure there aren’t any urgent
issues before heading home.
1PM
11:30PM
Technical Architect and Business Analyst log issues with reports under development
on the project’s on-line issue tracking system.
3PM
1:30AM
Business Analyst drafts requirements for new report and posts it on the project portal.
5PM
3:30AM
US PM checks in with US team to discuss priority issues that the India-team needs to
handle.
7PM
5:30AM
US PM sends detailed email to India PM prioritizing tasks that need to be worked on.
Tasks are logged in the issue tracking system also.
11PM
9:30AM
India team begins its workday, working on the report discussed yesterday, reviewing
the requirements for the new report and issues logged in the system. The India PM
discusses priorities with the offshore team.
12:30AM to 8AM
11AM to 6:30PM
Indian team continues to do develop and work on issues.
8AM
6:30PM
Onsite and offshore team have a conference call to review the newly developed report.
The Offshore PM runs the report and shares it with the extended team in a web
session. Issues with the report are discussed and logged. The next set of reports to
be developed is discussed and assigned.
How do the offshore resources gain access to the development environment?
There are several modes under which an offshore team can gain access to the physical
development environment. The choice is largely dependent on corporate standards and any
policies concerning network access and data security. In most cases, the access is provided
through a secure VPN network. The VPN options available include: Cisco VPN, Windows
VPN, Citrix based technologies or HTTP based VPN’s.
Once the offshore resources connect to the VPN, there is really no difference between an
offshore developer and an onsite developer. The offshore resource can just use the client
software to connect directly to the development Server for development and testing. Certain
actions that can take up a lot of data transfer (e.g. Schema Updates) are best done through
remote connectivity software like Windows Remote Desktop Client or PC Anywhere.
How can offshore resources perform their tasks if direct access to the development
environment is not feasible or permissible?
A complete parallel environment is setup offshore. The offshore team needs to be provided
with sample dimensional data and dummy fact tables. All development and testing is done
offshore. For a reporting project, an onsite developer would be required to restore the
metadata and to test/run the reports against the real data.
My organization has a specific development methodology and way of conducting business
– how would distributed development accommodate this?
An organization’s culture and specific processes will greatly influence the success of a
distributed development initiative. For instance, a company that insists on significant
interpersonal, face-to-face interactions will find it difficult to use offshore teams for any
software development. Development processes do vary from organization to organization
as well. Though an iterative methodology is preferable for BI development, some organizations
use traditional waterfall methods. Levels of development maturity can vary as well (i.e.
CMM 5 vs. CMM 3).
14
For distributed development to be successful, it is critical that the vendor and client discuss
upfront each other’s preferred processes. Most experienced vendors will align their
methodologies to their client’s. This however should be weighed against the project’s
requirements, since this alignment is likely to affect the project’s budget, scope or schedule.
What do I need to consider when transitioning production BI projects to an offshore services
provider?
Too often, much attention is paid to the evaluation, negotiation and finalization of contracts
with onsite/offshore vendors, with little regard for how the project(s) will be transitioned.
A formal transition plan is absolutely necessary to ensure that all tasks are properly transitioned
according to schedule. All parties must have a clear understanding of their roles and
responsibilities for the transition. At a minimum, a formal transition plan for migrating a live
BI application to a distributed mode should have the following eight components:
1. BI system “health” diagnostic – This diagnostic should include an assessment of
the technical environment, security requirements, resource availability, BI system use
characteristics, technical performance, training needs, documentation and other
elements critical to developing a successful transition plan.
2. Communications plan – Consider all constituents and communicate transition
plans and “what to expect”. The communications should include abstracts from the
vendor contract including Service level agreement (SLA) terms and KPIs (Key
Performance Indicators). All parties should be updated on transition progress no less
than weekly.
3. Staffing plan – Complete plans required for onsite and offshore teams. The onsite
project manager should interview all offshore team members prior to accepting them
for the team.
4. Technical infrastructure and cutover plan – Assessment of the current architecture
and any gaps that need to be filled to provide offshore support. Typically, there will
be a time period during which redundant onsite and offshore support is provided
prior to complete cutover to offshore support.
5. Knowledge transfer plan - Knowledge transfer activities may require that members
of the onsite team work side-by-side with the onshore team for some period. A
training plan and an Operations Guide should also be developed to communicate
15
knowledge to additional offshore team members.
6. Security plan – Especially for BI applications with sensitive data (i.e. customer data),
there needs to be a plan to secure confidential data and information. The plan should
include offshore background check practices and technical infrastructure requirements.
7. “In-flight” issues plan – How to handle pending support and development requests.
8. BI system growth plan – To assist with capacity planning, staffing and overall
communication of the BI system’s “vision”, the business sponsors should communicate
their expectations of how they expect the system to grow (i.e. number of users,
additional data sources, additional reports, new applications, etc). At a minimum,
this growth plan should feature a 12 to 18 month time horizon.
How do I get started?
Begin by clearly understanding and articulating your reasons for pursuing a distributed
development initiative. The following tend to be the reasons that most organizations pursue
distributed development for their BI and other IT projects:
•
To save anywhere from 30% to 80% on labor costs
•
To free up in-house resources for higher value activities
•
To provide on-demand, as needed staffing
•
To access a highly educated and skilled offshore workforce
•
To access skill sets that are difficult to find domestically
•
To accelerate development times by taking advantage of time zone differences
Once the organization understands why it is interested in using an onsite/offshore model, a
business case should be developed. Some elements often missed in business cases are extra,
hidden costs such as transition, travel, infrastructure, software, communications, and
redundancy related costs.
Next, contact potential vendors and conduct the necessary vendor due-diligence, based on
your organization’s goals and the decision criteria outlined elsewhere in this FAQ. Make sure
that the vendor has the BI expertise you need for your projects. Many IT consulting companies
16
are either skilled at BI project delivery, or at offshore software development, but only a few
have mastered both.
Following the selection of your chosen vendor and the necessary contractual negotiations
(including communications plans, processes and risk mitigation plans) comes the important
task of selecting the project (or pilot) most appropriate. Regardless of whether it is a project
or a pilot, it must be of a significant enough size to assess the appropriateness of distributed
development for your organization, given your overall goals. The initial project will also give
you the opportunity to understand and fine-tune mutual processes and dynamics. Most will
recommend that you start with something small, but make it meaningful.
About InfoCepts
InfoCepts specializes in planning, designing and building business intelligence and data
warehousing systems that provide exceptional value. Our InfoCepts Insight Delivery (IID)
methodology assigns project tasks to onsite and offshore locations based on where the tasks
can be optimally completed at the lowest cost while exceeding our customers’ expectations.
Please visit us at www.infocepts.com or call us at (301) 915-0446.
17
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement