e-Talk Radio: Paul Hopkins, November 2000


own trap of only doing certain projects based on who's screaming the loudest, and not necessarily the right things. It's one of those things where you have to institutionalize it, you have to keep working at it, and also eventually show the value to the customer. Because if the customer doesn't care, they're really not going to buy into the process as well. But if they actually see some output, and some work being done around it, I believe that that will help sustain it.

Carol: So it sounds like you've also improved the communication with your customers. And as soon as we come back from these messages, we'll talk more to Paul Hopkins.

Welcome back. I'm Carol Dekkers, and my guest this week is Paul Hopkins, who is the director of information technology for one of Honeywell's largest divisions. And we've been talking a little bit about a measurement program that Paul instituted last year. In the IT industry, oftentimes we talk about software being developed. We've had guests on the show who have talked about getting requirements right, we've talked to people about getting the teams right. And one of the things that we haven't spent a lot of time talking about, and which is really the focus of our practice, my company, Quality Plus Technologies, is in the software measurement industry. And before we went into break, we were just going to ask Paul about this measurement program. Now that you've got numbers, and you've got cost per function point and you can do the comparisons, and you can manage your projects more like construction-type projects, what's been the value? Have you had any feedback from your customers, who are actually getting the software?

Paul: Actually, we have, Carol. What's been the advantage for us is being able to have some facts and data to talk to the decisions. And what we'd like to do is not make the decision the IT problem or make it an IT decision. What we'd like to do is have the customers make the decision for us, based on all the facts that are on the table. In the past, it was very difficult to sell a program or to justify cost, benefit, those types of things, without a lot of facts. And here's just another example of things we can provide and put on the table to help decide and help the customer decide what should be done or not done. And once it's all up there, and you're actually comparing apples to apples at that point, it's fairly clear for people to make that decision.

Carol: So would it be similar to sitting down, if you're the system builder, if I'm the customer I could basically take a look across a number of alternatives in how I want my system built, or what I want built, and be able to say well, this one will cost me $200 a function point, and this one will cost me $300 a function point. But with $300 a function point, I'll get some additional stuff.

Paul: Correct. You might get additional functionality. We actually use it for some enhancements as well. So if people are asking for minor enhancements to applications, we let them know that it's going to add this much functionality, but it's going to cost this much because it's just a little more complicated to do. So they might actually make some decisions not to do things based on that.

Carol: Now, do customers understand these things? Do customers…Your customers…Are they internal customers, external customers? Who would be your

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.