establishing a successful multi-shore support arrangement
TRANSCRIPT
Establishing a Successful
Multi-shore Support ArrangementDecember 2010
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.
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
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
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
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
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
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
The Service Level Agreement
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
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
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
Assessment -> Transition -> Steady State Support
A well defined / rigorous process
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
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
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
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
Top 5 things you MUST get right
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
Avoiding Long Term Erosion of Quality / Value
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
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
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
Q&A
24
You can ask questions by entering them in
your Webinar control panel - in the ‘Questions’ section