This presentation covers the following aspects of enterprise IT support related to off-shore or multi-shore outsourced solutions.
- 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
2. 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.
3. 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
4. Our Solutions Expertise & Services
Business-Driven Solutions Perficient Services
• Enterprise Portals End-to-End Solution Delivery
• SOA and Business Process IT Strategic Consulting
Management IT Architecture Planning
• Business Intelligence Business Process & Workflow
• User-Centered Custom Applications Consulting
• CRM Solutions Usability and UI Consulting
• Enterprise Performance Management Custom Application Development
• Customer Self-Service Offshore Development
• eCommerce & Product Information Package Selection, Implementation
Management and Integration
• Enterprise Content Management Architecture & Application Migrations
• Industry-Specific Solutions Education
• Mobile Technology
• Security Assessments
Perficient brings deep solutions expertise and offers
a complete set of flexible services to help clients
implement business-driven IT solutions 4
5. 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
6. 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
7. Categorization of Support Models
‘Tiered’ model (escalation or hybrid)
Types of support models: • Tier I – Entry points for all incidents (1.800 / eMail / chat / ticket). Generally
• Tiered (most common) limited trouble shooting skills, but able to handle repeatable solutions
• Single Point of Contact (SPOC – ITIL) • Tier II – Handles more complex issues and non-standard trouble-shooting.
Sometimes merged as SPOC. May do some minor fixes – hot patches.
• Touch and Hold (SEG / TAG model)
• Tier III – Development level support. Complex troubleshooting / resolution.
• Front-Line / Back-Line (Real Time Support) May involve code changes. Often original / ongoing development team.
• Required to ensure measurable operational quality, efficiency and value
PMO /
• Combined stakeholders from both customer and provider
Oversight
• Weekly / monthly / quarterly reviews (dashboard) on key SLA metrics (more on this later)
• Generally more significant development that requires design and potential architectural changes
Significant • New functionality / features
Enhancements / • New development - full lifecycle: Requirements / Construction / Deploy
New Initiatives • Classical team mix: PM / Tech Arch / BA / Development / QA & Testing
• Larger degree of ‘High Touch’ roles – especially early in project lifecycle
Tier - III
• Generally CR queue driven
On-Going
• Simple fixes as discovered by Tier II / III support
Application
• Minor enhancements (compliance, security, features, etc) as designed by Tier III
Maintenance
•
Tier - II
Release management (patch, regular)
• Incident driven (1.800 / eMail / trouble ticket )
Production • May involve proactive monitoring and job resolution / restart
Tier - I
Support • Can involve data issue resolution or configuration resolution
• May implement trouble-shooting / resolution scripts
‘Classical’’
• Continuous improvement through trouble-shooting standardization
Tiered Model
8. Multi-shore : Operational ‘Reference’ Model
Customer Delivery Methodology
• Full Lifecycle
• Rigorous (CMMI-L5)
Steering Committee • Agile / Iterative
• Strategic Planning • Multi-Shore Proven
• Budgetary Planning / Mgmt • Highly adaptive to change
PMO / • Demand Forecast / Estimation
Oversight • Project Portfolio Management
• Performance Management
Delivery Center PMO
Program Office
High Touch Roles Development / QA
• Project Management • Highly Scalable
Significant
• Architecture • Architecture / Design
Enhancements / • Business Analysis • Iterative Development
New Initiatives • Some Development • Full service QA
On-Going CR based enhancements
• Capacity based team sizes
Application
• Work queue focused
Maintenance
• Escalation from production support
Operational Lead
Production On-call Support Model
Support • Scaled as required to meet SLA
• ‘Bucket of Hours’ per month approach
e.g. Denver, Columbus, etc… e.g. Global Delivery Center (Hangzhou, China)
US - Onshore Offshore
10. The Service Level Agreement (SLA)
• The SLA is the substrate that defines the operating
parameters by which the Customer and Service
Service
Customer Provider will operate, and by which the quality / value
Provider
of the Service will be judged.
• It is imperative that the SLA be ‘comprehensive’ and
Service Level Agreement (SLA) ‘achievable’ and all that expectations align around it.
Key Contract Considerations
• Scope of support (technology, systems, levels) • Out-of-band maintenance expectations / metrics
• Methods & procedures (M&Ps) • Continuous improvement expectations / metrics
• Governance process • Resource constraints (locations, turn-over)
• reporting, metrics, review period, change management, etc. • Warranty and indemnification
• Definitions of severity • Transition option (costs / timeline / etc..)
• Hours of support (and time zone) • Dependencies (technologies, escalations, etc.)
• Volume and incident characteristics assumptions • Dispute & Termination clauses (with/without cause)
• Baseline incident response time (by severity) • Standards and guidelines (architecture, doc, etc)
• Baseline incident update time (by severity) • Documentation / Knowledge Management
• Incident resolution time (by severity) • Security processes and IP protection
• Weighted quality metrics (analytical and subjective) • Infrastructure (tools / communications)
• Fee structure (including tiering, durations, volumes) • Software licensing and environments
• Performance based Incentives and penalties • Press release / publicity considerations
• Proactive monitoring expectations • Cost / benefit analysis and tie-backs 10
12. 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
14. Assessment to Launch – Process Model / Approach
• Scope Definition • M&Ps / SOPs
• SLAs • Pilot
• Organizational Model
Mobilization & • Knowledge Mgt • Refinement / Baseline
Assessment • Application Maturity Ramp-up
Pilot and Launch
• Tools / Connectivity • LAUNCH
• Transition Roadmap
• Team on-boarding • On-Going Support
• Go-forward SOW
• KT and transition
Define scope (applications, levels Close application gaps from Pilot launch and tracking /
of support and SLAs) assessment adjustment / refinement
Define Organizational Model Finalize scope and application Weekly / Monthly Reporting
(roles and on-boarding roadmap Quarterly governance review
responsibilities, processes, linkag Define Methods & Procedures (see example artifacts)
es / guide-wires) (Standard Operating Procedures) Validate support levels
Define Steering Committee across all levels of development (application team sizes, support
model (strategic and support hours per month, SLAs)
planning, budgetary planning Finalize Service Level Ramp-up / ramp-down based on
and portfolio management – Agreements (SLAs) project portfolio (on-going
including estimation) Establish / populate Knowledge support, maintenance and 14
Define PMO model Management repository enhancements and significant
(measurement, reporting, issue Establish tools / connectivity enhancements / new
management, escalation, etc.) Ramp and on-board team development)
Assess target applications members
Define tools, connectivity, etc. Knowledge Transfer and
Create transitional Roadmap (as- application transition
is / to-be with time-
lines, costs, etc.)
15. 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
16. Detailed Application Assessment
Portfolio of IT Applications ‘scored’ across variety of dimensions to determine readiness
for multi-sourcing, onshore / offshore ratio and necessary actions.
Architectural Complexity Operational Support SDLC Process
Integration Points Attrition Impact Risk Mgmt Process Maturity
Architectural / Design Pattern Usage Support Schedule Communication Plan Maturity
Architectural Weight Support Resources Development Methodology Maturity
Level of Stability Degree of Change Reliance on Tacit Knowledge
Instability Issues Change Mgmt (Planned/Unplanned) Collaboration Tools
Maintenance Effort Change Impact Documentation
Other known issues/concerns Change Mgmt Process Maturity Cross Training
Criticality and Visibility Organizational Effectiveness
Growing Business Needs Service Levels Awareness
Enterprise Vision Issues/Concerns/Gaps
User Profile Budget
=
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
17. Assessment Evaluation Deliverables - samples
Application Readiness Scoring Organizational Plan
New Program
Functions Sponsor (ABC)
SDLC Process Onshore Offshore
4 Director
(ABC)
Director
(PRFT) Project
PMO Manager
Lead (PRFT)
Criticality and Visibility 3 Tacit Knowledge ABC PM1
Requirements Web Tibco EDI/Operations ABC Macess1 Development QA Test
Lead (PRFT) Lead (ABC) Lead (ABC) Lead (ABC) PRFT PMO1 Lead Lead
2 ABC Dev1 ABC Dev1 ABC Ops1
PRFT PM1 Tibco 1 Portal 1 Tester 1
ABC Lead
ABC Dev2 ABC Dev2 ABC Ops2 Tibco 2 Portal 2 Tester 2
1 ABC SME1
ABC Dev3
ABC Adm4
ABC Adm1
PRFT Dev1
ABC Ops3 Tibco 3
Tibco 4
Portal 3
Portal 4
Tester 3
Tester 4
ABC SME2 ABC Ops4
ABC LDAP1 PRFT Dev2 Tibco 5 Rotating 1 Tester 5
ABC SME3
Degree of Change 0 Org Effectiveness ABC SME4
PRFT Dev1
PRFT Adm1
PRFT Arch1
Tibco 6 Rotating 2
ABC SME5 Program Management Team
PRFT Arch1 • Portfolio Management & Prioritization
ABC SME6 • Supply/Demand Management/Tools
PRFT BA1 • Recruiting QA Testing Team
• Performance Management • Dedicated QA staff for eCommerce
PRFT BA2
• Vendor Management • Off-hour test execution
• Offshore Communications • Automated Testing Tools and Processes
• Release Management • Defect Management Procedures
• Quality Assurance
Requirements Team
Level of Stability Operational Support • Centralized BA/SME team and Domain Knowledge
• Requirements Repository
• Requirements Traceability and Approval Processes
• Use Case Development, Prototyping
• Usability Best Practices
Arch Complexity eAcme (ABC) - 25 Perficient (PRFT) - 13 Offshore - 20
Resource is ramping-up Weeks
Current 50/50 60/40 Resource is fully productive
1 2 3 4 5 6 7 8 9 10 11 12 13
Combined Existing Team 50 38
CNC (- 5)
(12 resources ramp-down) PRFT (- 4)
30 days Contract (- 3) 60 days 90 days
Resource Ramp-up (ONSHORE) 2 3 4
PMO Lead (PRFT-US)
Requirements Lead (PRFT-US)
Senior Business Analyst (PRFT-US)
Project Manager (PRFT-US)
Resource Ramp-up (OFF-SHORE) 1 3 9 13 20
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)
Total Transition Costs ($444 K) 38K 43K 49K 49K 55K 48K 49K 40K 28K 17K 11K 9K 7K
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)
Financial Model Transition Plan
19. 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
21. 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
22. 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
23. Follow Perficient Online
Perficient.com/SocialMedia
Daily unique content about content
management, user experience, portals and
other enterprise information technology
solutions across a variety of industries.
Twitter.com/Perficient Facebook.com/Perficient
23
24. Q&A
You can ask questions by entering them in
your Webinar control panel - in the ‘Questions’ section
24