Example Reflection – Learning Launch

Challenge

I was hired by the IT department some months ago and my challenge is to analyze and improve internal  IT process to increase efficiency to meet service level agreements from IT to the rest of the organization.  This project is about identify the amount of work done by IT staff (3 area supervisors, 8 specialist by  system/function and 2 administrative associates) related to support; for instance the number of times  when a printer is broken or when the end-user can’t process an invoice in the system. The company does  not have any tool/software dedicated to record/track these activities and there is no budget assigned to  buy/rent any. I was assigned with a 2-month time limit to present a suggested solution to address the  need or not of embrace a formal process to record users’ requests and to identify the inefficiencies of  how IT is supporting associates across organization. There are multiple complains on the quality of IT  service and exceeding the time to fulfill support requests

Selection

During the first month I used design thinking tools that help me during my journey to meet with  supervisors/manager from human resources, customer service, supply chain, engineering, production  areas and top management to gain an understanding of their expectation on IT service as well as to  identify additional improvement opportunities. Additionally, I met with IT staff to analyze what  information/data/tools they have on-handy to fulfill users’ requests. Then I was in position to use learning  launch to test a prototype that helps to evaluate the idea of using a tool similar to a ticket system

Application

The launch was divided in 2:

a) Record any request made by end users for a small group representative of each of the main

departments. The first goal is to measure the amount of times end-users requests support from  IT. This confirmed that IT supports a larger number of incidents as initially estimated. One  challenge was the practice on how users request support  (by email, chat or in person) informally  and now they did it in the prototype designed in excel.  I trained end-users on how to use the  template indicating the fields they need to enter so that the IT specialist could have all the  information they need to reduce the possibility to go-back to end-user to request missing  information. I expected that this would improve the time to respond and avoid unnecessary steps   Another expected result was to design a process to request IT services internally.

b) Ticket assignment among IT staff based on the system/services each support. One of the

administrative associates in IT was in charge to assign “tickets” to the correspondent specialist. I  expected to identify which specialist has more tickets assigned to identify opportunities in both  systems/applications and in distribution of task among IT staff. One of the main components of  the second launch was to evaluate if the list of services was enough so that users have all possible  values at the moment they selected the type of service as well as to evaluate how easy was for  them to submit a request. On a similar context the goal was to identify how easy/hard was for the  IT associate to assign a ticket based on the information submitted by the user and if the IT

specialist had the information required to perform his activities to solve the issue. Each of the  participants had the opportunity to provide feedback to the process/tool. This information was  expected to complete the evaluation of this launch. The pilot lasted for a couple of weeks

Insight

The expectation of the launch was to confirm if the assumption of a tool/workflow would make evident  that this would help to both end-users and IT specialist to easily communicate, track and record request  services. The results demonstrated some resistance to use the tool, some of the requests were not  recorded in the tool and instead were addressed directly between the end-users and IT-specialists. The  main reason mentioned in the feedback sessions was that both think that for urgent cases it is faster to  request the service directly without going to the new process/tool

The above discovered the need to manage urgent cases differently. This insight will be considered for  further releases

Approach

Some interesting data was obtained as a result of the launch. The number of requests received was higher  than anticipated. One positive feedback was related to the easiness to track/monitor progress of the  requests statuses without needing to ask and wait until the specialist is available to provide an update.  Other features that were mentioned to enrich the design include:

•  Document solutions to most common cases so that users can solve some of them on their own

•  Other specialists could take advantage of technical solutions documentation; therefore those  tickets could be solved by another specialist and not only by the person who usually fix them

•  Add features to the prototype vs buying a specialized tool would be evaluated to identify  cost/benefits

All the above insights will help during the next steps and was faster/easier to develop vs a full approach  of evaluating a tool including all IT services which would have taken longer and would have implied more  resources in a larger project.

