Given the enormous costs of IT projects, Management rightly wants to know not only how much money is being spent, but also what the business is going to get out of it. Ms. Dekkers and Mr. Hopkins talk about how measurements can help demonstrate the value of IT projects, and can help prioritize them.
TEXT TRANSCRIPT: 7 November 2000
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.
Announcer: Welcome to Quality Plus e-Talk! with Carol Dekkers. This program will focus on the latest in the field of technology. All comments, views, and opinions are those of the host, guests, and callers. Now let's join Carol Dekkers.
Carol: Welcome to Quality Plus e-Talk! It's Carol Dekkers here, and I run a company called Quality Plus Technologies, and we teach companies how to build better software. We do that through process improvement, through measurement, and a couple of other things. And I was fortunate enough last year to have actually the company that my guest works for as one of our clients. And I'd like to introduce you this evening to Paul Hopkins. Paul Hopkins is currently the director of information technologies for the engines strategic business units for Honeywell International, based right here in Phoenix, Arizona. He is responsible for the overall engines IS organization reporting to the engines and systems strategic business unit. He's involved with customer computing, engineering computing, concept and production development and operational support. And recently, he's been acquired, and I guess the entire company has been acquired by GE. So I'd like to welcome Paul Hopkins to the show.
Paul Hopkins: Great. Thanks, Carol.
Carol: And today we're going to talk a little bit about some of the challenges that Paul and Honeywell and some of the large corporations have been facing in the IT industry. We're going to talk a little bit about kind of the challenge that came to Paul in particular last year. Paul, do you want to mention a little bit about where you sit in the organization, what are some of the challenges that you faced? I know that you've held a lot of different organizational positions at Honeywell, and formerly when it was Allied Systems. Allied Signal. And you actually even held a role as the HR director?
Paul: I've had varying roles, yes, yes. Basically, if you think about the IT world, and what we're seeing, it's really not a new problem. It's something that's been around for awhile. But understanding the value that you bring to the business from an information technology organization. And what's unique about this is that there are ways to do it, but it's one of those things that tend to fall off the plate, and people tend not to focus on until they really have to again. So coming into the organization a little over a year ago, the question was posed, how do we measure productivity? How do we know we're doing the right things for the business? And actually, at that point, started our quest down the path to understanding how do we measure ourselves, how do we know we're doing the right things, and how do we eventually institutionalize that, so that it's something that can sustain over time.
Carol: Now Honeywell and...Honeywell's IT budget has got to be millions, billions.
Paul: Yeah, let's stay with the millions.
Carol: Okay. It's a lot more money than you and I will ever have, probably.
Paul: It's more than ten dollars, yes.
Carol: So in terms of this expense, as a lot of people kind of might view it...They might take a look at IT spending, and I think that's traditionally how people have looked at it. It's IT spending. We've spent all this money on information technology, and what exactly did we get for it? What's the value to the business? What do we get for the millions of dollars that we're spending on acquiring hardware and software and all these people who keep working in this industry and working in our company? Is that kind of some of the things that you were being challenged with?
Paul: Yeah, that's exactly what it was. Not only did we have to justify our spending and the resources that we would be utilizing, but certainly with any company, you have a limited amount of resources, a limited amount of dollars, and you really need to focus on what's being done and what needs to be done to advance the company. We've done some, I've done some experimenting with the topic of function points. Having used them probably in the last ten years, at a previous job at General Electric as well, have used function points. And we could talk a little bit about that in a minute. But using function points helped me understand the application portfolio, in terms of what do we actually provide to our businesses here, from a systems standpoint? And then utilizing ROI, or Return on Investment, calculations. Actually return on function point calculations. Literally, how much are we spending to build an application, and what is the business going to get out of that? So actually experimenting and utilizing those calculations to help us prioritize, help us demonstrate the value of doing one project over another.
Carol: So you've essentially got, I guess like every IT department, a list of a lot of different projects that you could choose to do. A lot of different activities that you could choose to work on. A lot of different spending that you could choose to do. You could choose to do training. It's kind of like, how do you dole out these things to get the best value?
Paul: Right. And the particular challenge also is that typically we always fall back on ROI, or payback. And you know, that's typically a very short view of the money aspect. Versus what's the long-term payback, or what is the company actually going to benefit from later on?
Carol: Some people would kind of say, if I spend $4 million on this computer system, to develop it, including the hardware and software and the costs of developing it, I guess if I save 15 people, well that will pay for itself in two years or three years or something like that.
Paul: Correct.
Carol: That's the typical return on investment that you're talking about.
Paul: Correct. And it's a very simple calculation, and a lot of my finance peers love that view. But I also take that a bit further and say literally, what is this going to provide the business? Not necessarily the payback. And you can factor in many other different things around that. Such as, if you have value around applications that you build, around speed, how fast do you develop that and how fast do you get that to market? It could be life expectancy. How long will this thing last? And then there's also the aspect of percent growth. Literal dollar growth to the bottom line. How much does that provide? So you can use these factors to help weigh in actual application development and prioritization.
Carol: And one of the things that you alluded to, that you mentioned before, is the concept of function points, which is one of the things that Quality Plus Technologies came in and actually provided expertise to your company, and being able to set up, run a function point program. And maybe you can…I could explain it, but I'd rather have you kind of take a look, tell our listeners, what are function points, what could they deliver as part of a…as measuring software?
Paul: Okay, sure. Function points, for those that aren't aware of that, in a very quick layman term, it is really just measuring the size of an application. In the past, we used to look at lines of code, for example. But in today's world, where technology is changing so rapidly, you need a measure that will help you understand the size of an application, independent of technology or changes within the industry. The function point, Carol, in and of itself, does nothing but tell you the size of an application. So for example, it could be 100 function points is the size of an application. When you put time measures, if you put time across that or dollars, then you can start calculating dollars per function point, hours per function point. And what was necessary for us was to gather and collect a quick baseline of our portfolio. How many applications, and of those applications, what was the size of our function points? And you alluded…Your company actually came in and helped us do this in a very quick turnaround, that allowed me to catapult this program and its process into the first of the year. Helped us through one of our busiest seasons as we were getting Y2K efforts as well. So that was a great help.
Carol: So what you were after was the size of all of the software that you had in your portfolio, which I kind of liken to how big was your village in square feet?
Paul: Correct.
Carol: How big were you supporting, how big was this thing, at a point in time, how big was it becoming? What were the renovation projects that you were working on? And one of the articles that a colleague and I just finished writing was basically what's the difference between lines of code and function points. And function points are like the square feet for software that reflect really what you're going to build, as opposed to lines of code kind of being the components, or number of boards, or something like that.
Paul: That's right. And imagine all the general contractors trying to come in and redecorate or enhance your house, and you're not really having a clear picture of how big it is to start with. If you don't have the function point piece.
Carol: Right.
Paul: So that basically jump-started our measurement program. And once I'd done that, then I was able to add quite a lot of metrics around that - quality metrics, financial metrics, including cost per function point, cost per function point to develop an enhancement, those types of things. Which allowed me to then start building prioritization, functionality delivered to a business became a priority.
Carol: So you could take a look at, say, three projects that you had on your list to do, and you could say, typically, you know, if you've got a list, people will say, well, mine's the most important. You've got to work on mine because I'm the VP, or I'm the chief of staff, or…Work on mine, because I really want mine. And, were you able to come up with better estimates of how much it would cost? Were you able to come up with some sort of functionality size, kind of like the size of what each of these systems would be before you get started?
Paul: Right. The beauty of function points, actually is you can get a fairly good estimate of the size or how big the application is, early on in your requirements phase. So you actually have a good idea of how big this animal is before you start wrestling it. Then what I've done is ask people what's really important to them from an IT delivery stand. Speed, for example, was of utmost importance. Deliver it fast. There was obviously a quality piece to that. But then also I added the part about percent growth to the bottom line. How much is this application really going to provide growth to this company? If that was a major goal of ours.
Carol: Something like, potentially, say, automating a spreadsheet. If somebody just wanted a whimsical type of application, where they wanted to automate a spreadsheet, it might cost them $800,000 to just automate what they would do manually. You were able to start taking a look at that compared to some of your mission-critical things, and say, well, mission-critical things will deliver higher value to the company?
Paul: Correct. And you can play with those metrics, in terms of understanding what's important to the business at that time. Company goals will change over time, so you need to be able to be flexible to understand if you're measuring the right stuff to do the right stuff. We also go through a process called a Waterline process, where projects are prioritized based on the need to the business. And you only have so many dollars as an IT function, and you literally draw the line of where the projects stop and where the projects start. And if things below the waterline need to be done, literally you move it up on top of the line and take something off of the top. So you kind of swap things out as well, based on that.
Carol: It sounds like you actually gave something back to managers, who were not necessarily IT savvy, who were not necessarily in your department, to be able to set some priorities themselves and to be able to see and have some control over which projects that they think should get done first.
Paul: Yes. Absolutely. We just had that happen a couple of weeks ago. We did it with a roomful of vice presidents and functional leads, where literally we went through the 2001 operating plan, and based on priorities and needs, actually worked it out as an organization of priorities for projects to be funded for the next year.
Carol: Now, I'll play devil's advocate for just a minute. It seems to me like this is the way that every company should do it. That every company should have the measures, they should be able to figure out how big their systems are, how much value it should be before they get started. But, I have a feeling that what you're going to tell me is this isn't the way that most companies actually go about doing their priorities. And it doesn't sound like this is how you would have done it last year or the year before.
Paul: You're right. And it's not common…The problem is common, by the way, to every company. And not everybody is addressing it. And we tend to fall into our 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 customers?
Paul: Most of my customers are internal to the business, so we're supporting a lot of the functional areas as well as the business enterprises. And quite honestly, they do not understand the concept of function points, nor would I expect them to. What I do expect them to do is be able to understand some basic facts of prioritization and understanding what one comparison means to another, in terms of value to the business. So if you get into the very specifics about function point counting, it doesn't help with the customer. What does help is actually providing them some totals in dollars and numbers that will help them understand what that's going to provide them for the business.
Carol: And is this a better situation than it used to be?
Paul: Absolutely. In fact, this is…Some customers are calling this a benchmark year, because this is the first time they've really had such an engagement with IT in our planning for 2001. And even though we've got lots of things on the plate to do, and we can't do it all, but they're certainly more engaged than they've ever been in the past and actually are pretty excited about that piece.
Carol: And it must be exciting, too, to sit down with people in systems who are, and because I am one I can say this without fear of recrimination, but we're really nerds, a lot of times. We're like master electricians, master plumbers, and we talk in terms of subroutines and maps and amount of hardware, and I can just see it as being very daunting if we were talking in that type of language with customers. They must be quite relieved to hear business terms, in terms of dollars and alternatives and really business talk as opposed to technobabble.
Paul: Correct. And on the other side, too, is you have…I compete with a lot of salespeople out there, trying to meet with my customers to sell them products, just the latest and greatest toys, which provide little or no value for a lot of money. So it also helps put the damper on the bells and whistles that the customers might be excited about, and not realizing really what they're getting.
Carol: Right. And it's always a challenge, because you see…As systems people, we cannot control the amount of information that comes in. And there's really nothing to prevent somebody, and I do the same thing…You read a magazine, you say, look at these great new toys! They sound great. Do they work? Well, who knows? And we'll be back after a few short messages. If you'd like to call in, our call-in number is 866-277-5369, and we'll be back in a few minutes with more of Paul Hopkins from Honeywell.
Welcome back to Quality Plus e-Talk! I'm Carol Dekkers, and my company helps people, helps organizations like our guest's organization, to build better software by improving their processes, so that they can build better software. My guest this week is Paul Hopkins, who is the director of information technology for Honeywell's engines strategic business unit, here in Phoenix, Arizona. And I think that we have a caller. Hello.
Caller: Hello. Boy, is it a nice refreshing reality after voting to listen to you guys.
Carol: Well, that's a nice compliment.
Caller: Well, business is reality. What we're voting for are figureheads. With a little bit of power, not that much. I, from what I understand, I enjoy the function points method of what you're doing. And I only came into the house about 20 minutes ago, so I only got in on part of it. But is it almost like having an IS blueprint for what, to fulfill my requirements for my business on a day-to-day basis and ways of measuring those specific arenas?
Carol: You're very insightful. Actually, some of my articles, I've actually used the blueprint. In software, your requirements, the things that you need, the functions that you need software to do are your floorplans.
Caller: You mean like inventory control, perhaps billing, perhaps…
Carol: The functions that you need. You need to produce some bills, you need to produce some invoices, you need to create items on invoices, that type of thing. Those are all business functions, which would be similar to having rooms. You know, kitchens. Well, how big is the kitchen? The kitchen's 10 by 10. How big is your function? Well, it's by function point.
Caller: Right. I love the way you put that across. And the gentleman is Paul…
Carol: Paul Hopkins.
Caller: Hopkins? And you're in Phoenix? Super. I'm going to have to make it a point to…Now, do you do this with your business? And I didn't get your name.
Carol: Carol.
Caller: Carol. And is this something your business has done? Or is it something that…
Carol: Yes. What our business does, is our business teaches people how to measure their software. And one of the techniques we teach is how to make sure that number one you have good requirements, that they can be measured, and that by using function points we can kind of assign a square foot value to your system.
Caller: The reason I'm saying…I won't say who I am or where I work, but I have, and I'm sure that any other big bureaucracy has wasted tons of money in trying to figure out function point measurement, core IS. Because it's quite expensive, I know that. And if you do it wrong, you've got a humongous problem that has to be revamped.
Paul: It can be expensive, for a couple reasons. But quite honestly, my approach has always been being very practical about it.
Caller: Oh, no, I'm not saying yours is. I'm saying without this type of measurement capability, and laying out the groundwork up front, a lot of money has been wasted on…I only know that from my small bit of experience in the overall bureaucracy, to see how things don't work and have to be revamped. And it just makes for insanity, and the employees get really crazy, like me, because you don't want to see IS people come near you because they're demons. You know? And my opinions, I kind of let them know. I don't think they know what they're doing.
Carol: Well, and I use the example when I do my training. One of the things that happens is in information technology, you need to do estimates before design. And if you and I sit down…
Caller: You need to do what?
Carol: Estimates before design. Before we'd even designed the system. So if you and I sit down at lunch, and you say, "Carol, I really like the system you did for Paul last week. I kinda sorta wanted to do the same thing. How much time will it take?" And I think about it to myself, and I think, "Okay, gee, I think it's going to be kind of this big, and use this kind of software," and I get back to you, just off the top of my head, and you guarantee you're not going to hold me to it. I say 12 person-months, and you say, oh great! And the next thing we know, you've put together a project list, and you put "Carol Dekkers said 12 person-months."
Caller: Exactly.
Carol: Well, if we go into requirements, and we find out, we flesh out the requirements and we find out that you want billing and invoicing and that type of thing, and I get the size out in terms of classified requirements, I put that into a model, and I come out with 46 person-months. I know what you're going to think of me. You're going to look at me and say, "You know what? You don't look like Bozo the Clown, but gee, you know, how could you be that far out? You must have used lunar cycle and shoe size to do your estimates."
Caller: You know what, though? I have found…I sold real estate, and I was taught by a very good person, when estimating possible sales, proceeds of a home, always go on the low end. The worst possible scenario. But you've also got to have the guts to have that person listen to that. Most people want pie in the sky, which is not reality. But most people sell that way. Because they're afraid of losing the sale or speaking the truth to their customer, which will benefit both the customer and themselves. You know, repetition sales are a lot better and referrals, rather than that hard, cold calling and closing a situation for all the wrong reasons.
Carol: When, in software, what happens is you're asking me to build something, and the 12 person-months was right, because we only thought it was 100 function points. When we get into requirements, we find out that guess what? It's actually 400, so no wonder we were off.
Caller: Isn't it similar to where like certain vitamins and nutrients will work for me in a specific way and help me tremendously, but they could possibly kill you because your system is not the same. You see, we're all the same but we're all different?
Carol: Right.
Caller: It's like all businesses and all departments.
Carol: One of the different things we can do with measurement, with function points, that Paul did in his company, is demystify IT.
Caller: Exactly. I agree. Because people a lot of times are afraid, and I'm an older woman who decided to embrace technology when it came on board, when a lot of people were just saying I'm not going to do it, and that's that. And I'm going, my gosh, if I want to better myself, I'd better learn to embrace it. And you're right, once you embrace it and knowledge is power, it's not to say that I know how to do everything, but I understand the concept and I know the people who can do specifics. As in, what you're doing and what Paul is doing. Because you're the experts in those realms.
Carol: I still get intimidated when I walk into Radio Shack and they start throwing around the acronyms. I don't know about you, Paul.
Paul: Yeah, you're right. You're right. But what you're hearing is someone that has had to deal with an IT organization and understand what they're trying to do. And just as an option that we've used to help demystify, as you say, what are we trying to get out of what we're providing?
Caller: Right. And you have contact numbers. I got the 727 number for Quality Plus Tech and the Web site. And Paul, does he have a contact number?
Carol: Paul, do you want to give out your email?
Paul: If you'd like, actually…Yes, my email is [email protected].
Caller: Okay, I might even…Gosh, Paul would be worth buying a dinner and two lunches just to pick his brain.
Paul: Food works. That's good.
Caller: Hey, with guys that usually does, and I'm an excellent baker and gourmet cook, so I always ply my way. I've always worked with men, and that's the easiest way to get to the brain. I'm not saying you're like that, Paul. I'm sure you're more of an intelligent nature.
Paul: I appreciate that.
Caller: But keep talking. You guys are phenomenal. I'm going to run this by some of our IT people at work, and see if this won't help them. Because sometimes they run around in circles.
Carol: And we've also got articles, if you're interested, in understanding the basics of function points. We've…I've put together a few things, like in CrossTalk, which is the journal of Defense Software Engineering, which you can get free subscriptions to.
Caller: Now, is this on your site, or do I call your 727…
Carol: If you send me an email, I promise I will put you in touch with the CrossTalk people. And you can get free subscriptions. They actually like that, because it's a Department of Defense funded journal. And the more subscribers, the more funding they get.
Caller: That's fine. You guys are phenomenal. Keep talking. I'm running around here doing things, but listening.
Carol: And we're going to go into break. And we'll be back shortly with more of Paul Hopkins.
Welcome back to Quality Plus e-Talk! with Carol Dekkers. I'm Carol Dekkers, and my guest this week has been Paul Hopkins, who's the director of information technology for Honeywell's engines strategic business unit. And Paul, our caller seemed to hit a nerve that seems to be pervasive throughout the customers, and throughout the customer's side of building software. Would you agree?
Paul: Absolutely. And the points were well taken. And it's something that I think the IT organization has wrestled with for years. And quite honestly, as an IT professional, we have to get beyond the point where IT is an art. It is a science, and it's a way for us to communicate and translate the business needs into the value of the bottom line. So clearly, we need to be able to talk and communicate a common language with our customers, so that decisions and priorities can be set appropriately.
Carol: And I think one of the things that you've done successfully at Honeywell is turn the IT group around. To be able to talk customer talk.
Paul: Yes, and it's one of those…And I think you'd find pockets. You'll find localized we do better in some areas than others. But it's certainly a model that people can follow and work toward. And certain customer groups are reacting, responding really well to it. So again, it's one of those ongoing processes that I think will just get better in time as we mature.
Carol: And the thing that I've found about using function points, which really is like the square feet on a floor plan. One of the biggest values I've seen, and that our clients have seen, is when you make changes, and changes are inevitable…Changes are…People say, well gee, if we just didn't have the users changing their minds…Business changes, life changes, and when change happens part-way through a project, it's similar to saying to your builder, you know what, I really wanted a bay window. 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 taken over…Somehow, two organizations have meshed, that being GE and Honeywell. What's next on the horizon, do you think?
Paul: Well, we haven't meshed yet. I mean, we're still at a point where we're going through some kind of sharing and understanding each other's companies at this point. I've worked at GE in the past, and actually that was my exposure to function points, so I know there is usage of software measurement at General Electric. Outside of that, quite honestly, I will pursue and continue down the path of software measurement, because I just believe that that's what it is. It helps me understand and helps me answer the questions that are tough to the business.
Carol: Right. And we'll be back with a wrap-up with Paul Hopkins after a few short messages.
I'm Carol Dekkers, and I've been talking this week to Paul Hopkins, who's the director of information technology for Honeywell's engines strategic business unit. And I'd like to thank you, Paul, for spending the last hour with me on a wonderful Tuesday evening, where there's a lot of groundbreaking things going on. Our caller alluded to the fact that it's actually the election night, so I think a lot of people are going to be moving from the show, going directly into watching TV. So I'd like to say thank you, Paul, for spending the last hour.
Paul: Thank you. It was a pleasure. Thank you for being…letting me be a guest here.
Carol: And we've learned a lot of things in the last hour. We've learned that measurement's important, that measurement can deliver value, that we can talk better to our customers between the software division and the customer-focused side of things about building better software. And if you go onto the Web site that we had listed, you'll find articles and introductory information for anyone who's interested. And you can also send to me or Paul an email. Next week's show, we're going to have a reschedule of Roger Pressman of Roger Pressman Associates, who has written a phenomenal book, actually one of the best books I've ever read on software engineering management standards. He actually calls it A Manager's Guide to Software Engineering. And it's like an encyclopedia of things that you need to know about software engineering. And he's written a number of other books. So we'll be talking to Roger Pressman. Paul, in closing, do you have a few more words of wisdom that you'd like to leave our listeners with?
Paul: Sure. Yeah. It's one of those things with measurement. It's a tough concept to get IT folks to think about, but really, think of it as a realist. You know, why would you be doing it? Why are you doing it? I always let people to know get beyond the ROI management piece of that, because that is just one aspect and quite often doesn't really serve the business well all the time. And don't be intimidated by measures. And act very entrepreneurial in your approach to the measures. Why do you need it? Act as if it's your own money, and understand why you want to prioritize projects based on that.
Carol: It's almost like doing the goal question metric. I'll leave with kind of a send-off. One of the things that I've always looked at, and that a lot of our clients phone in, is what should we measure? Should we start capturing function points? And I liken it to going shopping. If I'm having everybody over for dinner, and I go shopping first, and I walk through the fruit/produce area, and I say, you know what, mangoes are great, they're on special. And rice is on sale. And I load up my shopping cart, pay for it, get home, and say, boy, I sure as heck hope I can come up with a recipe, with everybody coming over, with these things I've purchased. That's like metrics. Okay, let's go and measure function points and let's go measure this, and boy, I sure hope I can cook this up into a metrics program.
Paul: Exactly. You must be clear about why you're doing it.
Carol: And you took a methodological approach. You looked at the goals. You looked at what Honeywell wanted you to find out. What they wanted you to tell them. And figured out the metrics based on that.
Paul: And it's clearly based on what are the values of the business. What do we value as a company, around the bottom line for businesses. And so the speed, the bottom line growth, the life expectancy of systems, those types of things.
Carol: And would you do it again?
Paul: Absolutely. It's the only way I know how to answer a lot of the tough questions, quite honestly.
Carol: That feel doesn't cut it in IT anymore. You can't say, well, I feel I know we're doing better.
Paul: Right. And it's hard to prove that.
Carol: Well, it's going to be an interesting rest of our evening, as we look and find out who's winning the election, who has won. When we come back next week with Roger Pressman, I guess we'll have all those answers. So thanks again, Paul. Have a great evening, everyone.
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.
