e-Talk Radio: Paul Hopkins, November 2000


I'm willing to pay for it. What's it going to cost? In software, it may be something like, oh gee, I forgot about this report. Are you better able to respond to that today?

Paul: Absolutely. And I think that the part that's interesting when those changes happen, all IT professionals develop and work around what we call "scope creep." And it's something where the scope of the project just gets bigger and bigger. And not by anyone's fault, but just time. And what we've found is that using function points and counting the system, we can actually demonstrate to folks this is how much larger this application got, from the first time we actually identified the requirements. So from a cost perspective, that's why it costs a little bit more. From a time perspective, this is why it's taking a little bit longer. But you can actually show and demonstrate what you've added from day one that was not necessarily in the original request.

Carol: Right. The responsiveness…Programmers typically don't like to be measured. And I think one thing that our company tried to do, and you can tell me whether we were successful or not in working with you, was to depersonalize the measurement. We're not measuring the programmers. We're not measuring the people. We're measuring what they're developing, the size of the software.

Paul: Clearly, your folks helped do that. Helped break down those barriers, especially in a measurement area. For IT professionals, it a little scary. But you also need a champion there that's going to prove and say, through words as well as actions, that this measurement is not for people. It is absolutely for the business, to understand how we build system solutions. As far as measuring of people, we already have those measures in place. We do that already, whether function points are in place or not, quite honestly. So, it clearly needs a champion as well as, in terms of the training and the exposure to it, needs to be done fairly delicately as well.

Carol: And the other thing I think is that we should tell our listeners is that function points isn't for everything. And every program. It depends on what you want to measure and what you want to improve on, that…You know, it's like saying it's square feet for every construction project. For every improvement process. And I think I'd like to commend you. One of the things…I wrote a paper called "The Secrets of Highly Successful Measurement Programs." And one of the critical success factors has nothing to do with the technical merits of implementing a program, but has everything to do with the supportiveness, the motivation of the managers that have been involved. And I think that you are truly one of the success stories. That you truly walked the talk and stuck with all of your programmers, even when the test got going.

Paul: Thank you. Thanks. And it takes a huge team, a huge effort, at least out of the chute, to get this thing going. And I share with my folks, you know, my concerns about the program or my concerns about measurement, why we're doing it, why we need to continue to do it. And it just takes time. You just need a few zealots out there that will continue the program, but clearly, you need some support from higher levels to help bolster that and keep it grounded.

Carol: What's next for Paul Hopkins? What's next for measurement at Honeywell, and now that you've been taken over, or merged, or you've

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.