We’re now providing very good service levels, and we receive mostly good customer satisfaction scores. However, my question is, how can we take it to the next level? Do you have any recommendations on how to integrate support and development processes? Is there any way to apply your reengineering methodology to product development?

Dave’s answer: That is an excellent question. It seems that most companies have gotten the message about customer support. They understand that it can make or break the company and that having a “cool” product is not enough…you need to back it up with good customer support. Either they’ve improved their support operation to a level that is effective and satisfactory, or they realize that they need to do so. However, it seems that most companies are not aware of the hidden opportunities within their product development organization. It probably would surprise most companies to learn that the average software development organization has the potential to improve productivity by 35 percent or more and to increase quality by 50 percent or more!

Now…are you wondering what product development has to do with customer support? The answer is simple. The best way to improve customer satisfaction and customer support is to deliver better products. The best way to improve a product is to establish an effective process for getting the appropriate customer feedback into the development cycle, ensuring that the development processes allow you to get new product versions turned out quickly and with high quality. Therefore, embarking on a thorough process improvement and process integration program (between product development and customer support) typically will result in higher quality products, shorter development cycles, improved customer satisfaction, and significant bottom-line savings.

I’ll begin by commenting on the organizational structure that is alluded to in the question. Although it is not uncommon to see development and support reporting to the same executive, it generally is not a good idea. While these two organizations should collaborate, they also provide a check and balance. The situation is similar to the relationship between quality assurance (or quality control) and the production or manufacturing groups. In the hardware world (including traditional industries such as automobiles), it would be unorthodox for these tow functions to be part of the same organization. Sure, some companies can make it work. However, there is generally more value attained through the positive friction that results from having the two functions separated within the organizational structure.

I have two additional nuggets of advice on this topic. First, it is critical that you establish a very solid process to facilitate collaboration between the support organization and the development organization. There are many ways to do this, but I’ll share what I think is the best approach. It is necessary to establish a position or group to act as the liaison between development and support. It is important that the group be positioned at a higher level than the rest of the support staff. Whereas most support organizations have at least two levels of technicians or engineers, this would be the third (or top) level.

The reason for this separation (from the rest of the support staff) is to position the group higher and on a level that is par with development. For instance, if you call your customer support staff “technicians,” you might call the Level 3 (L3) staff “product support engineers,” giving them credibility with the development engineers. Don’t underestimate the importance of establishing a good environment that facilitates collaboration between the groups. You need this group to be respected by both support and development personnel.

L3 has three primary responsibilities. First, the group is the primary contact point between the other groups in the organization. It is much more effective to have a small group or single person to facilitate communication, rather than everyone in support running over to product development every time they have a question. This is similar to how you may have structured your relationship with your customers. They may have a help desk, and the users call the help desk when they have questions. The help desk can answer most of the questions, and they only call you with the tougher problems. By filtering the noise through L3, we minimize the impact on product development. So, L3’s responsibility is to field the questions from the rest of support, acting as a buffer and performing as the representative of support on those issues that truly require the assistance of product development.

The second key responsibility of L3 is to learn new products and bring that knowledge back to support. When I implement this model, my expectation is that the L3 staff will spend more than half of their time in development. They should be working closely with the product development staff on upcoming versions. The closer the products get to release, the more hands-on the L3 people become. Often, I’ll assign a dedicated L3 person to perform product testing during the last 90 days or so before a new release, essentially “loaning” them to development or software quality assurance. Their job is to ensure that the product is truly ready for release. I realize “ready for release” doesn’t always mean “bug-free,” as most products are released with a few known issues. However, L3 must be aware of those issues and train the rest of the support staff (L1 and L2) so that they are prepared to take calls. When this model is functioning optimally, support is part of the product acceptance procedure, and they must sign off before a new product is released.

The third responsibility of L3 is to act as the spokesperson for support and the representative of the customer during the product planning and development cycle In most organizations, customer support gets involved fairly late in the development cycle (in some cases, very late). However, support can add significant value if they are involved earlier in the process. Studies have shown (yes, there have been formal studies on this) that the earlier support becomes involved and the more involvement they have, the better the resulting product will be. I’ve worked with organizations where support was involved from the very beginning, where they actually sat in on the initial concept meetings. There are two valuable advantages that can result from support becoming involved this early.

From what I’ve witnessed throughout my career, when support comes in later in the game, they offer good ideas, but the response they get is something like, “We’ve already defined all of the new features and fixes for this version. We can add that to the next version.” Whereas if support were involved earlier, it may very well be that their suggestions could be implemented, thereby incorporating key features and fixes that will have a positive impact on the customer. Also, the earlier support is involved, the more they feel that they are a part of that particular product/project team. That buy-in and sense of belonging will translate to a positive working relationship and further collaboration. When bugs surface later, which we all know will happen, these two groups can approach it as a mutual problem – without the typical finger-pointing.

The second part of my answer involves applying the proven techniques of reengineering customer support processes to the product development processes. Clearly, product development is dramatically different from customer support. There are very few processes that are even close. However, the techniques that are used to identify improvement opportunities are very much the same. Furthermore, the reengineering methodology that is used to develop and implement the improved processes can be the same.

This topic is one of the most important issues that companies are facing today. In the next issue, I will elaborate on the reengineering methodology and how to apply it to product development. After all, what could have a more positive impact on both the customers and support organization than improvement of the product? Any assistance that you can give to your peers in the product development for improving their processes and establishing a positive, collaborative rapport with support will be repaid through reduced bugs and improved supportability.

About the Author
Dave Brown is a management consultant, teacher, and writer. He teaches management training programs for Support Center University (www.SupportCenterU.com). He also consults with selected clients to establish world-class service operations and is considered an expert in the areas of process improvement, staffing models, and change management. You may reach Dave at his office in Boulder, Colorado, at 303-494-4932 or at dave.brown@SupportCenterU.com.

Have a tough question? Submit your question to Dave at dave.brown@SupportCenterU.com. He will respond to all inquiries, and if your question is selected for publication, you’ll receive a complimentary copy of his book, Optimizing Support Center Staffing.