Jan 2011Hotfix release Performance Analysis

1. Jan 2011Hotfix releasePerformance Analysis AnahitaZamani Marcelo Lorenzetti April 28, 2011

2. Agenda • Statement of Work • Background • Performance Analysis Overview • Drivers and Barriers • Preliminary Data • Design Approach • Conclusion • Next Steps • Q&A

3. Statement of Work • The overall goal of this project is to develop a systematic and effective troubleshooting strategy for service team based on • Lessons learned from the previous releases • The extensive Task Analysis done post Jan 2011Hotfix release

4. Background • Jan 2011, hotfix release introduces many escalation on Recording feature • About 300 issues reported from customers within the first month • Services team cannot catch up with the high rate of incoming escalation • There is risk on meeting SLAs. • VP of marketing wants to see the issue is resolved ASAP

5. Performance Analysis The performance analysis was conducted to: • Analyze the root cause of the current incident in production • Analyze the need in current troubleshooting process in Services team. • Propose short term and long term solutions for the incident • Propose next steps for the task analysis phases

6. Performance Analysis Process • Held a meeting with members of the Services Team • Collected data from bugs and escalation inventory • Compared the growth rate of incoming escalations with the previous releases • Identified the average time to resolve per escalation • Evaluated the accuracy of the current troubleshooting documents

7. Performance Analysis Optimal situation • Services team are self- efficient • The team has the overall knowledge of the troubleshooting process and specific knowledge in the following areas: • Known issues with workaround • Known issues with no fix and no workaround • Steps of the workaround • Internal troubleshooting tools • The required information to ask from the customers on any issue.

8. Performance Analysis Optimal situation (cont.) • Engineering to be involved only in troubleshooting brand new issues.

9. Performance Analysis Actual situation • New members of Services team do not have enough knowledge of the system. • All necessary information are not collected from customers • Internal troubleshooting tools that engineering are using are not exposed to Services team • Over 60% of Engineering team’s time is spent on escalations after each release

10. Drivers Based on actual situation the drivers are: • Clear knowledge of escalation process • Availability of adequate information on the system and known issues • Up-to-date documentations • Appropriate tools to increase the speed of the process

11. Barriers Possible barriers are: • Lack of documentation and training material • Lack or delay on reports generation • Lack of escalation decision making rules

12. Preliminary Data • Human Resources • Stakeholder • Mr. Jeffrey Duncan, Manager of Customer Services team • Wants a fast solution for “…a systematic troubleshooting procedure which streamlines the troubleshooting process and enables Services team to meet SLAs ” • Mr. JafarJayanka, GM of Engineering team • Wants Services team to take care of the customers issues, where no more than10% of the escalations bubbles up to his Engineering team

13. Preliminary Data • Human Resources (cont.) • Interviews results indicates that: • Troubleshooting guidelines are not well documented • Services team members do not have adequate knowledge of the product and changes made in each release • Engineers are not happy, since the bug reports do not contain required information and repro steps, which often leads the engineers to request for additional information from different sources

14. Preliminary Data • Non Human Resources • Hard Data Resources • Bugs and escalation inventory • Current troubleshooting documents • Existing Tools that engineering use internally • “Auto Blank Audio Detector” tool, developed by Aaron Set • “Blank PowerPoint pages detect and fix it” tool develop by Aaron Set • “Log parser” tool, developed by Scott Row

15. Design Approach • Training Proposal • In person and hands on training on the product and the troubleshooting tools and recorded sessions • Resources Proposal • Allocate temporary resources in Services to handle the current backlog • Allocate temporary resources in Engineering to help with developing the troubleshooting tool

16. Design Approach • Detailed TSG • Prepare step-by-step Troubleshooting guide • Update the existing Troubleshooting documents

17. Conclusion • The performance analysis has provided: • An overview of the current state of incoming escalation from production. • A closer look at the Services team workforce and work flow • A clearer understanding of the needed training and guidelines for troubleshooting • Our challenge: centralizing and unifying the homegrown troubleshooting tools used by the Engineering team, and making them available to Services team, along with needed trainings.

18. Next Steps • A continued review of extant data • A synthesis of the information collected • Work on developing the centralized troubleshooting tool • Work on existing troubleshooting guides and creating new ones on the missing area.

19. Q&A