How Six Sigma Can Help Perfect Tech Support

A friend of mine took on a new role at work as a technical product owner for a company’s suite of applications. It’s his job to ensure that all the people who use those vendor applications are on-line, happy, and productive. He asked me how I would use Six Sigma principals to improve the process and these were my thoughts.

First Understand the Process

First off, nothing can be done without understanding what the environment of the situation is. In Six Sigma terms you might consider making a SIPOC and doing light process mapping to get the lay of the land. One of my favorite career books, The First 90 Days, covers great, light-weight ways to apply similar techniques.

A SIPOC will of course help list who the suppliers are of the process (in this case the software vendors of the various packages he has responsibility for) and the inputs they supply to his process (the software, the licenses, the support, etc.) It will also provide a high-level overview of the process and the outputs created (working, installed software properly configured) to the clients (his end users.)

A SIPOC also affords the opportunity to understand the nature of the relationships of all groups involved in the process, perhaps even informing a stakeholder analysis. By combining these two powerful tools you could begin a dialog on what each group considers success and identify what is needed to close that gap or improve delivery.

Armed with a process map – the reflection of current day activities, and a stakeholder analysis involving each party noted in the SIPOC, you could then work to translate the needs of the client to the specific activities in the process that are needed to generate those results using a Critical to Quality Tree.

Reduce Variation

Six Sigma is all about reducing variation in our processes and bringing them under statistical control so we can then improve performance. Remember from our quincunx example that trying to improve performance before eliminating variation leads to poor results. It’s best to reduce variation first.

Tech support could leverage a process map to identify the many different ways they interact with their suppliers and clients and look for a way to standardize both processes, eliminating variation and thus lowering defects.

Eliminate Errors

Of course, Six Sigma refers to having an incredibly low defect rate. In order to avoid the cost of poor quality my friend could launch a DMAIC project aimed at process improvement by reducing and eliminating errors.

During the measure phase he might begin by keeping a log of all issues associated with the software suites he is responsible for. Of course there is the option of a more detailed data collection plan but that simple collection would be a good start.

Progressing into the Analysis Phase he could affinitize the issues into common types or perhaps use a Pareto chart to illustrate the most likely common cause of the errors. Once the most common issues are discovered he could then try to identify the root causes using brainstorming techniques, the 6Ms, the 5 whys, the fishbone diagram or a combination of all of them.
During the Implement Phase he would come up with innovative solutions that make it so that the most common errors never happen again. Of course a pilot plan and an implementation plan would be helpful

Before putting any of those changes into effect, it would make sense to determine the financial impact of the changes (ROI) to see if the savings were worth the cost of running the project. This could be done several ways depending on the project but here is an example.

Ex. 500 developer hours saved a month (by avoiding those defects) * $100/dev/hour = $50000 savings each month or $6M savings a year.

In the control phase he would determine how to lock in those gains. Perhaps making checklists or job aids or adding in specific alerts or instituting a specific process utilizing poka yoke principles making it impossible to make defects.

Lean Projects for Tech Support

Of course everything is not just defect reductions. Clients have many requirements and high quality is just one of them. (Remember, Lean is different than Six Sigma.) Others like cycle time reduction make excellent Lean projects.

There he could start off by making a value stream map of pain. If, for example it took 25 hours for a software installation request to get fulfilled. This is just the time it takes to work the current process. It’s not anyone’s fault, but a customer is waiting for 25 hours – even if Tech support only actually worked 1 hour and the rest was waiting for approvals or scripts to be run, there is work that can be done.

We all know what it’s like to wait on something that’s supposed to be automatic- not fun. When a process entails some small # of hours of actual work interspersed by lots of waiting or complicated by non-value added tasks, that waiting is waste. Quantify the ratio. Map where the waste occurs. Use that to make a business case for more authority / automation to decrease the pain on the clients by percentage.

Focus first on the items with the most waste (again you could use a Pareto to illustrate this).

Conclusion

Building a portfolio of these improvements and sharing them makes a practitioner a very valuable resource. For example, holding lunch & learn sessions where you cover lessons you learned creating these solutions brings a practitioner’s name to a wider audience and spreads the philosophy of continuous improvement through out the organization. All of a sudden the Lean Six Sigma practitioner is seen as a ‘force multiplier’ or a change agent; Adding the practitioner to an equation makes everyone around you better.

In other words, a practitioner who delivers business results becomes so good that leadership can’t ignore you. That helps you earn a seat at the table, benefits you, benefits your company, and benefits your clients. What more could you ask for in a career?!