|
There is always room for another tool in your bag of tricks. Customer Service, Sales, and Customer Relationship Management are generally considered a bit too touchy-feely or, frankly, annoying for most of us to give much thought to. But there is a lot we can take from them to use in CM. I’m not talking the rot-your-teeth sugary approach but the meaty ways to deliver quality, build and maintain customer loyalty (you know how to read that), and reduce our own cost and effort levels. In doing the research for this article, I realized there were too many opportunities and perspectives to cram into an eye-glazer of an article so it’s digestibly broken up into a small series of three articles. This first article is dedicated to knowing the customer and our own team. Part two will cover daily transaction opportunities and part three will look at strategic methods. Whether we appreciate it or not, we run our shops like mini-businesses. We use capital investments like SCM tools to provide goods and services to the other functional areas within the context of the Software Development LifeCycle (SDLC). As I said in the opening paragraph there are three strategic business goals that I believe we need to pursue in CM.
The first step of providing good service is knowing our own SCM team and ourselves. What can we provide? What range of tools do we have to support the lifecycle? How much load is on each individual in the team? What are our processes? What are our automation options? How knowledgeable is each member of the team? How much support can we get from management? This information defines the products we have available to offer. Knowing those items also allows us to both identify any weaknesses that can be corrected over time and push the strengths that become visible. Isn’t this extra work? Nope, it should be part of the audit functionality. We need to know these things to successfully perform the audit or they become part of our corrective actions. Just as importantly, we need to know what businesses we are in and what we are not in. For example, maybe we provide excellent CI control or change management options but we might choose not to administer a tool like TestDirector or ReqPro. This decision needs to be made before we go out looking for work. Most business startups that fail do so primarily because they lack focus and solid planning. After you know what your strengths and weaknesses are, decide what you can realistically be successful at. Then go after that business. Two points organizationally. Get the word “Engineer” in your titles. It's like "Vice President" in a bank. The title makes the customer happy but may not exert any direct power. You may think it’s semantics but it makes a difference. The engineering title is accurate and it often buys you enough initial credibility to get a seat at the table. Of course, after you start talking, you’re on your own. Secondly, get a “horse.” Find someone in a higher-level management position that can pull CM into the right meetings and make the connections that are so hard to make from the bottom up. You don’t have schmooze and blow sunshine but there is often someone who agrees with you up yonder or the CM group would have been phased out or crippled during budget negotiations. Just be aware of them and work with that person to stay on the same page. Everyone in CM knows that just because you hang up that shingle, people aren’t going to come running for you to control their processes and CIs. It requires a lot of persistence and excellence. It’s especially difficult if you are an existing shop at the bottom of the organizational heap. But it can be done. Not many of us are particularly equipped for sales but getting CM accepted requires more than just expecting people to buy into your system on it’s merits. Like any customer, they need to know that we aren’t just making a buck off them. They have to know they are getting something for the cost or aggravation. In order to do that, we need to know them. What do they do? Where do they get their inputs? What is required of them? How quickly do they need to turn around materials? Is it situational? Who are their customers? What tools do they have? Where do they want to take their department in the future? What forces are acting on them in the industry? What do we currently do for them? Do they like what we do for them? What do they need that we don’t currently provide? What do we provide currently that they don’t need? Sounds like a lot of work, especially if we are doing it for each functional area. We could take it that way but it can be done in an hour or two’s conversation. Plus, we get two results from the action. They know we asked instead of just telling them how it will be and two, we can better coordinate actions between groups. Half the battle of getting change to happen is talking to people in their own language and giving solid reassurances that it is in their best interest. When we understand the customer, we are far more likely to introduce concepts that will succeed. If we don’t do our homework, the customer will reject our ideas that seem perfectly suited to how they operate but perhaps trap them into the status quo. We need to ask them the up-front and then go back and ask if we’re getting it right. And listen to them. Hear them. Understand what they are saying. Often we try to see the client’s needs through the prism of our experience. We try to place them into readily configured solutions. Particularly when I came to my current client, it was very difficult to truly see the client as they were. Their needs were vastly different than any I’d experienced previously, even though they were, on the surface, a typical software shop. The solutions had to be custom. The client does not generally have a "production" environment, and the deliverables are one-time items. They aren't providing software as much as datasets. It required listening skills to say the least. The flip side of the selling is to understand what the client is willing to buy. Maybe we can give the client a fully integrated solution but if they aren’t willing to swallow the elephant whole, we may need to back off a bit and sell it piecemeal. Not matter how easily we can see the client desperately needs something, it’s ultimately their choice of how much they are willing to buy. All of this sounds like we have a huge agenda that will be added effort on our part. But we can incorporate a lot of this into the mechanics of things that are good for the organization. Create a Software Engineering Process Group (SEPG) that removes the stigma of CM being heavy handed. Let the players help drive the process forward. Air their complaints about the process. They’ll put their own efforts into being understood by the others and we’ll get interactive feedback. In a vibrant SEPG setting, we can walk issues through the different functional areas of the lifecycle, getting immediate answers and insights. Best of all, because they all had some say, they have some investment in making it work. They’ve done our customer service for us. It’s important to remember that they should be treated as unique customers on a transactional level but that at the organizational level we need the coordination that something, like the SEPG or CM, provides between the areas. Coordination enables smooth process flow reducing errors and, consequently, project cost. Running the CM organization in the terms of customer service or customer relationship management will change how we are perceived and how well we can do our job. If we know our own abilities, we can plan our next success. When we know our customers, it’s much easier to increase the quality of our deliverables, as they perceive it. We often face a lot of adversity before we even get onto the dance floor and making changes often means walking into an ambush. Using basic customer service techniques helps us keep in step and gives the organization a return on their investment in us. In the next installment, we’ll look at the transactional level opportunities that can add up quickly to success. Randy Wagner is a Contributing Editor for CM Crossroads and VP of Technology Development with Taylor Bean & Whitaker in Ocala FL. His experience ranges from major financial institutions to multimedia multinationals to the Federal government. Working in small to large project efforts has given him a unique perspective on balancing the discipline of SCM and enterprise change management with the resources and willpower each organization brings to the table. You can reach Randy by email at SR_71_98@yahoo.com.
Set as favorite
Bookmark
Email this
Hits: 5440 Trackback(0)Comments (0)
|
| Last Updated on Sunday, 05 August 2007 15:46 |



