establishing a successful multi-shore support arrangement

24
Establishing a Successful Multi-shore Support Arrangement December 2010

Upload: perficient-inc

Post on 13-Jul-2015

1.330 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: Establishing a Successful Multi-Shore Support Arrangement

Establishing a Successful

Multi-shore Support ArrangementDecember 2010

Page 2: Establishing a Successful Multi-Shore Support Arrangement

About Perficient

Perficient is a leading information technology consulting firm serving

clients throughout North America.

We help clients implement business-driven technology solutions that

integrate business processes, improve worker productivity, increase

customer loyalty and create a more agile enterprise to better respond

to new business opportunities.

Page 3: Establishing a Successful Multi-Shore Support Arrangement

PRFT Profile

Founded in 1997

Public, NASDAQ: PRFT

2009 Revenue of $188 million

18 major market locations throughout North America— Austin, Chicago, Cincinnati, Cleveland, Columbus, Dallas,

Denver, Detroit, Fairfax, Houston, Indianapolis, Minneapolis, New Orleans, Philadelphia, San Francisco, San Jose, St. Louis and Toronto

1,400+ colleagues

Dedicated solution practices

~450 enterprise clients (2009) and 85% repeat business rate

Alliance partnerships with major technology vendors

Multiple vendor/industry technology and growth awards

Page 4: Establishing a Successful Multi-Shore Support Arrangement

Perficient brings deep solutions expertise and offers a complete set of flexible services to help clients implement business-driven IT solutions

Our Solutions Expertise & Services

Business-Driven Solutions

• Enterprise Portals

• SOA and Business Process Management

• Business Intelligence

• User-Centered Custom Applications

• CRM Solutions

• Enterprise Performance Management

• Customer Self-Service

• eCommerce & Product Information Management

• Enterprise Content Management

• Industry-Specific Solutions

• Mobile Technology

• Security Assessments

4

Perficient Services

End-to-End Solution Delivery

IT Strategic Consulting

IT Architecture Planning

Business Process & Workflow Consulting

Usability and UI Consulting

Custom Application Development

Offshore Development

Package Selection, Implementation and Integration

Architecture & Application Migrations

Education

Page 5: Establishing a Successful Multi-Shore Support Arrangement

Our Speaker

Kevin Sheen – General Manager, Perficient Global Services

• Leads Perficient's CMMI Level 5 Global Delivery Center (GDC) in Hangzhou, China.

• 23+ years of consulting delivery experience

• Has delivered a wide variety of technology solutions in areas including:

– Communications

– New product launch

– Manufacturing

– CRM

– Retail

• Champion of Perficient's multi-shore Agile delivery methodology

• Regular speaker at industry events and tradeshows

5

Page 6: Establishing a Successful Multi-Shore Support Arrangement

Topics / Agenda

• Types of support models

• All hail the ‘Service Level Agreement’ - SLA

• Process: Assessment -> Transition -> Steady-State

• Top 5 things to absolutely ‘get right’

• Avoiding long term erosion of quality and savings

6

Page 7: Establishing a Successful Multi-Shore Support Arrangement

Categorization of Support Models

Production

Support

On-Going

Application

Maintenance

Significant

Enhancements /

New Initiatives

PMO /

Oversight

Types of support models:

• Tiered (most common)

• Single Point of Contact (SPOC – ITIL)

• Touch and Hold (SEG / TAG model)

• Front-Line / Back-Line (Real Time Support)

• Required to ensure measurable operational quality, efficiency and value

• Combined stakeholders from both customer and provider

• Weekly / monthly / quarterly reviews (dashboard) on key SLA metrics (more on this later)

Tier -

I

Tier -

II

Tier -

III

‘Classical’’

Tiered Model

• Generally more significant development that requires design and potential architectural changes

• New functionality / features

• New development - full lifecycle: Requirements / Construction / Deploy

• Classical team mix: PM / Tech Arch / BA / Development / QA & Testing

• Larger degree of ‘High Touch’ roles – especially early in project lifecycle

‘Tiered’ model (escalation or hybrid)• Tier I – Entry points for all incidents (1.800 / eMail / chat / ticket). Generally

limited trouble shooting skills, but able to handle repeatable solutions

• Tier II – Handles more complex issues and non-standard trouble-shooting.

Sometimes merged as SPOC. May do some minor fixes – hot patches.

• Tier III – Development level support. Complex troubleshooting / resolution.

May involve code changes. Often original / ongoing development team.

• Generally CR queue driven

• Simple fixes as discovered by Tier II / III support

• Minor enhancements (compliance, security, features, etc) as designed by Tier III

• Release management (patch, regular)

• Incident driven (1.800 / eMail / trouble ticket )

• May involve proactive monitoring and job resolution / restart

• Can involve data issue resolution or configuration resolution

• May implement trouble-shooting / resolution scripts

• Continuous improvement through trouble-shooting standardization

Page 8: Establishing a Successful Multi-Shore Support Arrangement

e.g. Denver, Columbus, etc…

Multi-shore : Operational ‘Reference’ Model

e.g. Global Delivery Center (Hangzhou, China)

US - Onshore Offshore

Delivery Center PMO

Production

Support

On-Going

Application

Maintenance

Significant

Enhancements /

New Initiatives

PMO /

Oversight

Program Office

Customer

Steering Committee

• Strategic Planning

• Budgetary Planning / Mgmt

• Demand Forecast / Estimation

• Project Portfolio Management

• Performance Management

High Touch Roles

• Project Management

• Architecture

• Business Analysis

• Some Development

Development / QA

• Highly Scalable

• Architecture / Design

• Iterative Development

• Full service QA

CR based enhancements

• Capacity based team sizes

• Work queue focused

• Escalation from production support

Operational Lead

On-call Support Model

• Scaled as required to meet SLA

• ‘Bucket of Hours’ per month approach

Delivery Methodology

• Full Lifecycle

• Rigorous (CMMI-L5)

• Agile / Iterative

• Multi-Shore Proven

• Highly adaptive to change

Page 9: Establishing a Successful Multi-Shore Support Arrangement

The Service Level Agreement

Page 10: Establishing a Successful Multi-Shore Support Arrangement

The Service Level Agreement (SLA)

10

Service Level Agreement (SLA)

CustomerService

Provider

• The SLA is the substrate that defines the operating

parameters by which the Customer and Service

Provider will operate, and by which the quality / value

of the Service will be judged.

• It is imperative that the SLA be ‘comprehensive’ and

‘achievable’ and all that expectations align around it.

Key Contract Considerations

• Scope of support (technology, systems, levels)

• Methods & procedures (M&Ps)

• Governance process• reporting, metrics, review period, change management, etc.

• Definitions of severity

• Hours of support (and time zone)

• Volume and incident characteristics assumptions

• Baseline incident response time (by severity)

• Baseline incident update time (by severity)

• Incident resolution time (by severity)

• Weighted quality metrics (analytical and subjective)

• Fee structure (including tiering, durations, volumes)

• Performance based Incentives and penalties

• Proactive monitoring expectations

• Out-of-band maintenance expectations / metrics

• Continuous improvement expectations / metrics

• Resource constraints (locations, turn-over)

• Warranty and indemnification

• Transition option (costs / timeline / etc..)

• Dependencies (technologies, escalations, etc.)

• Dispute & Termination clauses (with/without cause)

• Standards and guidelines (architecture, doc, etc)

• Documentation / Knowledge Management

• Security processes and IP protection

• Infrastructure (tools / communications)

• Software licensing and environments

• Press release / publicity considerations

• Cost / benefit analysis and tie-backs

Page 11: Establishing a Successful Multi-Shore Support Arrangement

Sample incident profiles and metrics

11

Severity Initial response Update interval Time to resolution

Metric Met?

Severity 1 15 minutes 2 hours 6 hours 95%

Severity 2 15 minutes 4 hours 8 hours 90%

Severity 2 15 minutes 4 hours 12 hours 97%

Severity 3 30 minutes 12 hours 3 days 95%

Etc… Etc… Etc… Etc… Etc…

EXAMPLE

Page 12: Establishing a Successful Multi-Shore Support Arrangement

Metrics / SLA Reporting and Dashboard

• Daily metrics capture built into support tools and process.

• Weekly status reporting on all key metrics.

• Monthly dashboard on metrics compared to established SLA’s, spend against budget, etc.

• Quarterly governance review by account executives to ensure quality and client satisfaction.

• True value / cost of service (rather than T&M hours)

• Monthly retrospectives and constant improvements maximize productivity

Page 13: Establishing a Successful Multi-Shore Support Arrangement

Assessment -> Transition -> Steady State Support

A well defined / rigorous process

Page 14: Establishing a Successful Multi-Shore Support Arrangement

Assessment to Launch – Process Model / Approach

14

AssessmentMobilization &

Ramp-upPilot and Launch

• M&Ps / SOPs

• SLAs

• Knowledge Mgt

• Tools / Connectivity

• Team on-boarding

• KT and transition

• Pilot

• Refinement / Baseline

• LAUNCH

• On-Going Support

Define scope (applications, levels of support and SLAs)

Define Organizational Model (roles and responsibilities, processes, linkages / guide-wires)

Define Steering Committee model (strategic planning, budgetary planning and portfolio management –including estimation)

Define PMO model (measurement, reporting, issue management, escalation, etc.)

Assess target applicationsDefine tools, connectivity, etc.Create transitional Roadmap (as-

is / to-be with time-lines, costs, etc.)

Close application gaps from assessment

Finalize scope and applicationon-boarding roadmap

Define Methods & Procedures (Standard Operating Procedures) across all levels of development and support

Finalize Service Level Agreements (SLAs)

Establish / populate Knowledge Management repository

Establish tools / connectivityRamp and on-board team

membersKnowledge Transfer and

application transition

Pilot launch and tracking / adjustment / refinement

Weekly / Monthly ReportingQuarterly governance review

(see example artifacts)Validate support levels

(application team sizes, support hours per month, SLAs)

Ramp-up / ramp-down based on project portfolio (on-going support, maintenance and enhancements and significant enhancements / new development)

• Scope Definition

• Organizational Model

• Application Maturity

• Transition Roadmap

• Go-forward SOW

Page 15: Establishing a Successful Multi-Shore Support Arrangement

Mobilization / Ramp-up Deliverables

• Operational M&Ps

– Incident reporting

– Incident response

– Prioritization

– Incident tracking

– Resolution (synopsis/root cause analysis)

– Escalation and collaboration

– Reporting and measurements (daily, weekly, monthly)

– Proactive monitoring

– Release support

– Post resolution knowledge capture

– Post resolution improvements (scripting, proactive monitoring, etc.)

– On-going problem management and resolution

• Baseline SLA’s

– Documented severity definitions and criteria

– Hours of operation, call back, updates, time to resolution, % compliance

• Knowledge Management (KM)

– Establish repository

– Baseline assets (design docs, user guides, trouble-shooting guides, contact matrix, technology guides, etc.)

– Update / management processes

• Connectivity / Tools

– Connection and security requirements, bandwidth, communication tools, etc.

• Pilot and Launch Schedule and Sign-off criteria

• On-going support SOW

Page 16: Establishing a Successful Multi-Shore Support Arrangement

Detailed Application Assessment

Portfolio of IT Applications ‘scored’ across variety of dimensions to determine readiness for multi-sourcing, onshore / offshore ratio and necessary actions.

SDLC ProcessRisk Mgmt Process Maturity

Communication Plan Maturity

Development Methodology Maturity

=

Multi-Sourcing Readiness Score (MRS):• Prioritizes applications and drives phase roadmap to multi-Shore multiple application• Identifies activities required to raise applications MRS score to threshold level

Reliance on Tacit KnowledgeCollaboration Tools

Documentation

Cross Training

Organizational EffectivenessService Levels Awareness

Issues/Concerns/Gaps

Budget

Operational SupportAttrition Impact

Support Schedule

Support Resources

Degree of ChangeChange Mgmt (Planned/Unplanned)

Change Impact

Change Mgmt Process Maturity

Criticality and VisibilityGrowing Business Needs

Enterprise Vision

User Profile

Architectural ComplexityIntegration Points

Architectural / Design Pattern Usage

Architectural Weight

Level of StabilityInstability Issues

Maintenance Effort

Other known issues/concerns

Page 17: Establishing a Successful Multi-Shore Support Arrangement

Assessment Evaluation Deliverables - samples

0

1

2

3

4SDLC Process

Tacit Knowledge

Org Effectiveness

Operational Support

Arch Complexity

Level of Stability

Degree of Change

Criticality and Visibility

Current 50/50 60/40

Application Readiness Scoring

Transition Plan

Organizational Plan

Financial Model

Combined Existing Team

(12 resources ramp-down)

Resource Ramp-up (ONSHORE)

PMO Lead (PRFT-US)

Requirements Lead (PRFT-US)

Senior Business Analyst (PRFT-US)

Project Manager (PRFT-US)

1 2 3 4 5 6 7 8 9 10 11 12 13

Weeks

60 days30 days 90 days

38CNC (- 5)

PRFT (- 4)Contract (- 3)

Resource Ramp-up (OFF-SHORE)

Offshore Manager (PRFT-China)

Development Lead (PRFT-China)

(4) Developers (PRFT-China)

(4) Developers (PRFT-China)

(4) Developers (PRFT-China)

QA /Testing Lead (PRFT-China)

(2) Testers (PRFT-China)

(3) Testers (PRFT-China)

2 3 4

1 3 9 13 20

Total Transition Costs ($444 K)Execution planning and execution ($44 K)

Document existing req, arch and design ($89 K)

KM and KT activities ($133 K)

Process definition / implementation ($111K)

Establish envirnmt / connectivity / security ($67 K)

50

Resource is ramping-up

Resource is fully productive

38K 43K 49K 49K 55K 48K 49K 40K 28K 17K 11K 9K 7K

eAcme (ABC) - 25

Onshore Offshore

Portal 1

Portal 2

Portal 3

Portal 4

Rotating 1

Rotating 2

Tibco 1

Tibco 2

Tibco 3

Tibco 4

Tibco 5

Tibco 6

Tester 1

Tester 2

Tester 3

Tester 4

Tester 5

ABC SME1

ABC SME2

ABC SME3

ABC SME4

ABC SME5

ABC SME6

ABC Lead

PRFT BA1

PRFT BA2

ABC Dev1

ABC Dev2

ABC Dev3

ABC Adm4

ABC LDAP1

PRFT Dev1

PRFT Adm1

ABC Dev1

ABC Dev2

ABC Adm1

PRFT Dev2

PRFT Arch1

ABC Ops1

ABC Ops2

ABC Ops3

ABC Ops4

ABC PM1

ABC Macess1

PRFT Arch1

PRFT Dev1

PRFT PMO1

PRFT PM1

Requirements Team

• Centralized BA/SME team and Domain Knowledge

• Requirements Repository

• Requirements Traceability and Approval Processes

• Use Case Development, Prototyping

• Usability Best Practices

Program Management Team

• Portfolio Management & Prioritization

• Supply/Demand Management/Tools

• Recruiting

• Performance Management

• Vendor Management

• Offshore Communications

• Release Management

QA Testing Team

• Dedicated QA staff for eCommerce

• Off-hour test execution

• Automated Testing Tools and Processes

• Defect Management Procedures

• Quality Assurance

Perficient (PRFT) - 13 Offshore - 20

Program

Sponsor (ABC)

Requirements

Lead (PRFT)

EDI/Operations

Lead (ABC)

PMO

Lead (PRFT)

Web

Lead (ABC)

Tibco

Lead (ABC)

Director

(ABC)

Director

(PRFT)

QA Test

LeadDevelopment

Lead

Project

Manager

New

Functions

Page 18: Establishing a Successful Multi-Shore Support Arrangement

Top 5 things you MUST get right

Page 19: Establishing a Successful Multi-Shore Support Arrangement

Top 5 Things to Get Right

1. Pick your support metrics realistically– Do you really need 24x7 with 15 minute incident response time?

– Long pole in the tent for most support is the hours of support, not hours working incidents

– Recognize that support organizations need to support multiple projects to price such service effectively. The lower the price, the more ‘spreading’ that occurs

2. Differentiate between an ‘ad-hoc’ support model using internal or contract ‘developers’ and a ‘predictable’ support model using a more appropriate level of resource

– Ad-hoc models often have a lot of unaccounted for ‘leakage’ costs (impacts to project work – both interrupt and restart time, buried hours, higher turn-over, etc.)

– Don’t expect your support resources to be as productive as an on-site developer that has been on the project for years.

3. Don’t short change the assessment / transition period / settling time– Nearly half of all offshore project failures are due to lack of preparation and collaborative planning

4. While theoretically, you should be able to treat support as an amorphous ‘black box’ – it’s in your best interest not to

– Recognize that support is really a collection of people, process and technology – all have certain degrees of freedom and constraints

– In competitive IT markets, the quality of the team is dependent on the environment that is created for them (team dynamics play a large role in getting the best bang for your buck)

– Ask lots of questions of your vendor around this topic (e.g. how do they enhance retention? What is the project related voluntary turn? Etc.)

5. Make continuous improvement / retrospective a key topic of governance– Assume that left to it’s own devices, quality / performance will degrade over time 19

Page 20: Establishing a Successful Multi-Shore Support Arrangement

Avoiding Long Term Erosion of Quality / Value

Page 21: Establishing a Successful Multi-Shore Support Arrangement

The Cost of Complacency

Many multi-shore support arrangements fall into the following ‘savings erosion’ trap

– Year 1 shows an increased to flat spend due to necessary assessment and transition costs

– Year 2 shows savings of 30% or higher (depending)

– Year 3 shows a decline in Q3 / Q4 of savings (~20% or less)

– Year 4 shows a complete loss of savings and often increased costs similar to Q4 / Q4 of year 1

21

Page 22: Establishing a Successful Multi-Shore Support Arrangement

The Cost of Complacency

• This can be avoided through a culture of continuous improvement and attention to performance– Don’t micromanage – but don’t ignore

– Understand the balance between cost / performance (non-linear)

– Quarterly governance meetings should always include ‘retrospectives’ and comparative performance analysis

– Delegate sustainable team management (training, retention, etc.) part of your suppliers performance measures

– Differentiate between ‘development’ and ‘support’ – don’t put ‘heroes’ in front of process for support which creates single points of risk and diminishes scalability

22

Page 23: Establishing a Successful Multi-Shore Support Arrangement

Daily unique content about content management, user experience, portals and other enterprise information technology solutions across a variety of industries.

Follow Perficient Online

23

Perficient.com/SocialMedia

Twitter.com/Perficient Facebook.com/Perficient

Page 24: Establishing a Successful Multi-Shore Support Arrangement

Q&A

24

You can ask questions by entering them in

your Webinar control panel - in the ‘Questions’ section