What is the financial value of customer feedback? Spend months or years building a product, most of that time planning for its deployment, release it with fanfare and all the good will you can muster—only to have customer after customer return your good deeds with comments, complaints, and suggestions for the next version. If it weren’t for the customer, life would be a lot easier. Right?
Of course not. Nothing is further from the truth. Customers are the sole purpose for a company’s existence; yet how well do we integrate their requirements and real-life experiences into how we build our products? Maybe your customers are internal. Be that as it may, your ability to manage their requests is just as critical as requests from external customers.
Many of us can relate to the all-too-familiar story of a lone project manager, sitting at a customer site on the opposite side of the country, waiting for a software vendor to call—a vendor whose application was integrated into his company’s software solution—and needing to respond to a customer question about a piece of functionality that wasn’t working as documented. As this project manager sat waiting for the phone to ring, his mind began to wander, and he found himself daydreaming about creating some kind of communication/teleportation technology that would allow him to reach through the telephone lines and smack the next person who had the nerve to tell him, “Well, we can’t seem to recreate the problem over here. Can you tell me again what the problem is?”
How often have we heard that response from our IT teams or some other technical support person—a total disconnect from what the field support team and the customer are experiencing?
Well, the software vendor finally called the project manager back with the expected response: “Can you help us understand the problem? What is your user trying to do? We can’t recreate your problem, and we need more information.” After a redeye flight to the east coast from California, followed by six hours of user training and a poorly reheated fast-food lunchtime feast, the project manager in this story was on the edge.
Both the project manager and the vendor tried looking at the issue logically, but they obviously had different perspectives. The vendor’s thought process was, “Just give me more information, and I’ll run some test scripts. We’ll try to figure out what is going on.” On the other side, the project manager’s thought process was, “If he doesn’t understand the problem in the first place, how does he know he can’t recreate it? What problem is he trying to resolve?”
Herein lies the fundamental breakdown among customers, the companies that serve them, and all of the organizations within the development food chain: There seems to be an endless volley among product management and engineering and engagement personnel to clarify exactly what the customer wants and needs, and what the development team can deliver. Most of us assume there is some kind of a “process” to handle the information being passed among the various organizations in the support chain, especially between our customers and any customer-facing organizations. In most companies, however, the “process” seems to consist of nothing more than an e-mail or a desperate phone call to the help desk.
Of course, this all-too-familiar scenario has a domino effect.
The random e-mail or call into the help desk rarely satisfies the customer’s desire to be heard. A customer who doesn’t think his or her input was adequately prioritized will often contact one or two other people at the company. In some cases, the salesperson may enter the customer request into a bug/enhancement tool, as will one of the other people the customer contacts (possibly a customer service representative). The members of the QA team see these two new requests coming into the system from two different people, and they flag the development team for an update to each. These requests look similar, of course, but while they ultimately come from the same customer, they are identified as two different issues. Meanwhile, the salesperson has discussed the issue with a product manager and a buddy on the customer service team, and the customer service rep who was contacted directly by the customer has also shared this information with a second product manager. (Are you following this?)
Because their perspectives about the problem all came from different discussions, the salesperson, the two customer service people, and the product managers now have different understandings of the problem.
One of the product managers adds the issue to her next review meeting agenda, while the second product manager goes straight down to engineering to talk about short-term solutions. Based on that conversation, engineering adds a small patch to the upcoming build schedule. Three days later, the salesperson logs into the bug/enhancement tool for an update. He doesn’t see an update, so he contacts someone on the QA team, who refers him to engineering, where he learns that a patch is being applied in the next build. He then contacts the customer to give him the great news. A week later the build is completed, two weeks after that QA approves the release, and the customer logs on to the new build—only to find that the problem he reported is still there.
Ouch.
OK, while this account is largely a dramatization, this problem of miscommunication across the various layers of companies is all too real. Some of the finest, most well-organized teams have fallen into this communication trap. To overcome it, you need to automate, plain and simple.
Water flows down the path of least resistance. In our experience, so do communications between customer-facing groups and product development teams. We all hate to admit it, but when it comes to solving complex software problems or responding to detailed customer functionality requests, development teams usually do what it takes to get the product out the door—even if it means bypassing specific customer requests with the knowledge that they’ll have to revisit the same problems later. This can be a financially risky decision. Keeping development on schedule and receiving continual feedback from your customers (and providing information back to them) should not be mutually exclusive.
The key to resolving this issue is knowledge. Knowledge comes from understanding the root of the problem. To understand the root of the problem, you need to understand the business use case under which the problem was identified, and for that you need good documentation and a solid feedback loop between your customer, your customer-facing team, and your product development organization. Documentation is the key.
The aspects of good documentation are simple: they must be clear, concise, consistent, and most importantly, they must deliver the expected results. This point deserves emphasis: it is one thing to create documentation that fulfills the technical requirements, but an entirely separate issue to create documentation that anticipates questions and provides solutions.[1].
But who has time for clear and concise documentation? Everyone, if you have the right tools and a pattern to follow. Put the tools in front of the people, and make them as simple as possible (the tools, not the people). The key to good documentation, as we all know, is accurate and thorough requirements. How do you get your globally dispersed sales team to input customer issues and requirements, you ask? Well, establishing this sort of two-way communication between your team and your customer is the point of this book.
Sure, there are a number of free tools available on the Internet, and many companies with time on their hands and money to burn have built their own solutions. However, we suggest using something a little more robust than the shareware or homebaked versions. Why? Security, for one. Most packaged solutions offer better control of access rights, roles and responsibilities, and data security. In addition, most off-the-shelf solutions offer a variety of integration and support options.
Figure 1-1 shows a simplified solution for a field team interacting with customers and a product team. The marketing requirements document (MRD) is typically the first pass on capturing a user’s business requirements and may include simple workflow diagrams and logical data flow of key systems.
In any implementation, the steps need to be made clear to everyone within the feedback loop. Again, this is a simplified model, but it will help you understand the various options available to you through ClearQuest.
Step 1: The customer contacts the appropriate customer representative with an issue or a suggestion. We suggest training everyone to get into the habit of pointing any user bug or enhancement request to someone on the team with ClearQuest access—or else make sure that anyone who comes into contact with a customer also has access to the tool, so you have one process for entering all issues. While people don’t seem to mind passing this responsibility over to someone else, your best strategy may be to provide everyone in your organization with a login.
Step 2: The customer rep documents the issue/suggestion, enters the information into the appropriate issue-tracking system—which, in this case, automatically logs an issue into the repository—and receives a tracking number. With a tight integration between ClearQuest and the issue-tracking system (which is customarily used and maintained by customer service), the rep can access the system at any point and get a status on this item. Each time the issue is edited (feedback provided), the issue-tracking system can be set up to receive an update, or an e-mail notice can be sent to the rep directly. (Note: While few companies will want customer service representatives to have access directly into a system that tracks engineering change requests, ClearQuest can be used this way.)
Step 3: Issues are sent to QA, while enhancement requests are sent to product management. You don’t have to set up your system like this, but in this model we wanted to make sure that the members of the product management team (our R&D shop) were responsible for all enhancement-related requests, so they could stay close to the customer usage patterns.
Step 4: The issues/enhancements are reviewed (Does the request make sense?), qualified (Is this a valid request?), prioritized (Where does it fit into our current activities?), and consolidated (Do I have any similar requests already in the system?). ClearQuest is then updated with the appropriate feedback, which, in this model, automatically notifies the customer rep who entered the information. Again, you don’t have to set up your system to notify the rep every time a change is made, but you might decide that you can better serve the customer by staying on top of any changes to the issue. You could just as easily log onto the system a dozen times a day.
Step 5: Based on the update, the appropriate development organization receives the request and fits it into the development schedule. These teams do not receive the bug/enhancement until QA or product management flags it. You’ll find this to be a great feature in itself. On previous systems, anyone who logged into the system, including the development team or an outside vendor, would have access to every single bug or enhancement that was logged into the tool. Not any more. Now they see only what you want them to see.
Step 6: The development organization works with QA to test any new code. Build, test. Build, test.
Step 7: Once approved, QA updates ClearQuest. Another great feature of ClearQuest: The issue isn’t closed until QA—and QA alone—decides it’s closed.
Step 8: The customer rep is notified that the item has been closed. E-mail notifications are great.
Step 9: The rep notifies the customer of the closure.
As with any tool, ClearQuest is not going to solve every problem, but if you don’t have something similar in place, it’s a great place to start. And, with integration into the full IBM Rational Software Development Platform, ClearQuest is one of the most powerful solutions on the market.
Based on this simple model, here is how we define the ClearQuest roadmap to success.
Understand that information means business value. Your product or service is what keeps your business running, and input from your customers is the lifeblood of that product or service. How you translate that customer feedback into your next version can mean the difference between version 2 and a decommissioned product.
Train your customer-facing folks to properly capture the information. Make yourself the documentation evangelist for your team or company. Advocate capturing requirements via entire sentences, as opposed to chopped-up fragments of what is generally regarded as written language. Persuade your team to break down each issue into logical chunks and to capture carefully the steps of the problem as well as the expected results. If you’re documenting an enhancement request, include detailed use cases that explain how the customer would use the new functionality and why the request is important. This goes a long way when the product team is prioritizing issues. A well-detailed description will move items to the top of the list, believe us.
Automate the mechanisms for entering information. We’ve used both homegrown solutions and Internet freebies (Bugzilla), but we prefer ClearQuest because it offers more features and flexibility, and also because of its robust integration into ClearCase and other development lifecycle tools. Implement this tool in a way that allows key personnel to easily access and share information. This should be a no-brainer: Log in, define the appropriate component, prioritize your information, and then leave your data. The easier you make it, the likelier they are to use it.
Set up a process for deciphering this information. Once you have the information, what will you do with it? It’s one thing to set up a vehicle for capturing and documenting customer information; it’s another thing to get your product development team to respond, so that your sales team can provide timely feedback. Make the tool part of your daily/weekly/monthly process for reviewing issues and enhancements. Assign responsibility to some lucky product manager, and keep the repository updated.
Assign tasks to necessary technical leads. The product team has responded, and the appropriate technical lead—whether part of your internal engineering team or part of a third-party development organization—is automatically notified. Actually, this is a big incentive for most product management teams. They are acutely aware that the sooner they respond, the sooner the issue gets assigned to an engineer and moves off their own plate. How’s that for motivation? Instead of the engineering team lead receiving e-mail notification for every single problem that comes across the product team, the system can organize and delegate based on components—and even based on severity.
Update the repository at each step. At each step of the process of solving your customer-defined issues, the repository is updated, the customer advocate has access to that information, and notifications are sent automatically. This is the key to cleaning up the entire process: Instead of pushing report after report across the organization, simplify, simplify, simplify. By following a defined process, and by using a single tool for managing this information, you’ll have one version of the truth.
Train customer-facing folks to log in and report back to customers. Every Monday morning, as you begin your week, you know that you can log into the system and get the latest update on any issue or enhancement that was entered into the tool the previous week. How powerful is that?
Issue management is the fulcrum point to a successful software configuration management solution—and the key to issue management is setting up the proper lines of communication between your team and your customer.
The purpose of this chapter was to explain the high-level business value for ClearQuest, and hopefully we’ve achieved that. Now we’re ready to jump into the meat of the program and show you how to get the most bang for your buck.
[1] Christian Buckley and Darren Pulsipher, “Destroying the Tower of Babel: Communication Through Documentation,” Rose Architect Magazine, January 1999:60–65