TEXT TRANSCRIPT: 15 February 2001
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.

ANNOUNCER: Welcome to Quality Plus e-Talk! with Carol Dekkers, brought to you by StickyMinds.com, the online resource for building better software. 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 your host, Carol Dekkers.

CAROL: Welcome to Quality Plus e-Talk! with Carol Dekkers. I am Carol Dekkers and welcome to show number seven. If you are joining us through the Internet, I hope that your connection holds. I hope that the sound quality is good this week. And if you are joining us from the Phoenix call-in area, I'd like to say welcome to the show as well. I am very fortunate with these cream of the crop guests that I've got; to have our guest this week who is going to share with you a lot of information on how to evaluate software tools. Elisabeth Hendrickson has over twelve years' experience as a practitioner and manager of software development. She has placed a lot of emphasis on quality assurance and testing. She has a proven ability to work effectively in small- to mid-sized companies during the crucial phase between really startup and IPO. She has got a lot of experience. She is the founder of Quality Tree Software, and she was so...so seized by one of her clients that she actually began working for them. And just this month, or just last month, January of 2001, she returned to consulting. And we are going to be talking to her about how to evaluate software tools and what you should really look for.

I am Carol Dekkers, as I mentioned to you, and I will tell you a little bit about me and what I do. I am the President of Quality Plus Technologies, which helps companies who are serious about building better software. We actually probably help managers to sleep at night. We allow them, through measurement and through working with them, to be able to manage, control, track, and improve their software processes. One of the things that we've developed is a calendar, which includes the CMMI, the capability maturity model integration, and also integrates with that an indicator that shows where function point analysis and other metrics can actually help them achieve the process areas. If you would like a calendar, please drop me an email at [email protected].

Without further ado, I would like to thank our sponsors, StickyMinds.com, the online resource for building better software, which is very compatible with a lot of things that my team and my company does. Elisabeth, I would like to thank you for taking time out of your busy schedule in teaching and presenting...to be part of our show this week.

ELISABETH: Well, thank you very much, Carol, I'm very glad to be here.

CAROL: It...it's pretty exciting...one of the articles that you published back in 1999 is a very good approach to evaluating software tools. From reading it, it is very clear to me that you have been through the ups and downs, and probably evaluated tools the wrong way before you figured out how to do it right.

ELISABETH: Yes, that's true. And I have also come in to organizations where they chose whichever tool had the best presentation from the vendor without determining whether or not it was going to meet their requirements long-term. And it is a very difficult process to get rid of a tool once you have made the wrong choice.

CAROL: And...and the wrong choice probably is not apparent unless you've actually gone through kind of a step-wise approach to evaluating a tool.

ELISABETH: That's very true. Until you know exactly what you hoped that the tool is going to give you. And not just at the high level of...of..."Well, this is going to solve all of our problems." So, I have yet to see a tool that can actually accomplish that, though, I have seen plenty of tool marketing material that would indicate to you that it is going to. You have to understand what all those problems are, so that you can understand whether or not the tool will actually address your problem.

CAROL: Would you compare it to if you went out shopping for a car or shopping for a vehicle based on going through the car ads in a magazine or going through your local newspaper and saying, "Oh, this looks really shiny, I should go out and just try it." Then going out to the lot and saying, "Oh, I...I love the S2000's or...and you really need to take a whole soccer team out and a two-seater roadster won't do it.

ELISABETH: Yes, that's absolutely true. If you have a family of five and you decide that you are going to get a little two-seater, then that had better not be your only car.

CAROL: Well, that's true, but I have to qualify something. I just...I went out and purchased my first midlife crisis car and it probably won't be the last. It's my total selfish car and it is an S2000 two-seater roadster, and I can take one person to the soccer game, and that could be my son but not my husband.

ELISABETH: But you see that met a requirement for you.

CAROL: Well, yes, yes.

ELISABETH: You had a requirement that you feel really good about your car.

CAROL: And I feel really good about me when I'm in that car.

ELISABETH: Well, now, would a minivan have satisfied that requirement?

CAROL: No, not at all.

ELISABETH: Well, see, you had a requirement.

CAROL: That's right. And there was a step-wise process to go through it, and I did pick the wrong vehicle the first time based on going with the wrong evaluation. Oh...very similar to software vendors. When I first bought my car about three years ago, we were lured into the Infiniti dealership by a promotion...

ELISABETH: Uh huh.

CAROL: ...for free. We went in and came out with a car. Went in to get a golf umbrella and came out with a car. They were that good. And I wanted a two-seater, roadster convertible at that time. So, I kind of know what you're talking about with software. But I think sometimes the software choice can be even worse and more costly than a bad car choice.

ELISABETH: Sure. Because you can resell that car. You will have lost whatever the depreciation was, but software licensing is a little bit different. And you can't just turn around and decide that you are going to sell your Segue or Mercury licenses to somebody else to recoup your cost.

CAROL: That would be an interesting thing, wouldn't it. To be able to have kind of a...kind of what they do with timeshares. You could resell your Mercury license at a discount.

ELISABETH: Yeah. And the licensing fees are actually only the smallest part of it. In order to get up to speed on any tool, you've got all of your training costs and you have the amount of time that you have invested in using that tool. And those scripts are not going to be transferrable to another tool.

CAROL: Right. And that...that's something I guess that you have lost. When you go through the step process, I would like for our audience to go through the kind of the steps that you have laid out in this article. And it was actually in STQE magazine. We've got two STQE'ers back to back in this series, which is kind of neat. In January/February 1999, in the STQE magazine, your article was called, "Evaluating Tools," and you laid out actually a very, very good five-step process. And I think it would be valuable for our audience to kind of know what is the critical pieces of each one. Step 1 you said, "Define the initial requirement." What do you mean by that? What do people have to do? Does that mean you can't go shopping for a tool first?

ELISABETH: Well, before you go shopping, you really want to understand what problem you're hoping the tool is going to help you solve. So, for example, if...if before I even start looking at tools, I don't even know whether I want to do GUI-based through the user interface...I don't know whether I want to do GUI-based testing or whether I am looking for something that is going to help me do command line base testing. If I don't even know at that level what kind of tool I'm looking for, then I am going to come up with a very, very huge list of possible vendors. And there is no way I can investigate all of those options. So, before I even start thinking about who I am going to get this tool from, I want to know what the tool is going to do for me. What capabilities does the tool need to have, who is going to be using that tool, do I need it to be extremely fault-tolerant, because that...that could restrict the...the kinds of tools I can use. Do I need it to work in a particular operating system? So, if all of our development is being done on MacIntosh, anybody who does not support MacIntosh in their tool set, there is no reason to even consider their tool, because they're not going to be able to help me solve my problem.

CAROL: Even if they've got something that looks and sounds really nice.

ELISABETH: Unless you're going to change your development environment, that's probably not going to help you.

CAROL: So, you're really talking about even before you look at any brochures, sitting down and defining really what you need. And in your article you talk about the tool audience. The fact that just because you are selecting the tool, you may not be the person that is using it. And there may be things that the person who is using it needs that you may not even know about.

ELISABETH: That's right. Or you may only be one of the people who are using it. So, a typical scenario that I see in software companies is that the folks who have been charged with choosing the test automation tool are the ones who will creating the automated test...and so that's great because they're really important stakeholders in the process. However, the folks who are going to be executing those tests ultimately are not given the opportunity to look at the tool.

CAROL: Interesting. And...and we're not just talking about, you know, test automation tools. This could be for any software tool, and I guess it could even extend beyond software. That if you are looking for anything in your business that is gonna help you do a better job, you need to go through this process. You need to step through and say, "What do I really need, what are my requirements, and what do I expect whatever I buy to deliver to me?"

ELISABETH: Absolutely! Like before you went looking for your new two-seater car, you already knew that you were not interested in station wagons, minivans, or anything that was not going to fulfill your basic requirement of, "I want to feel really good" in this car.

CAROL: Yes...and just in case anybody who is listening suddenly says, "Oh my gosh, consultants make too much money," I did not pay cash for the car; it is on payment processing and gee gosh, if you want to send us more work, we can absolutely use it. So, I wanted to still that myth before I go on further.

ELISABETH: I drive a 1993 Saturn.

CAROL: And...and that's good. You probably get far better gas mileage, and I can tell you that in Florida you would probably get...if you were in Florida, you would get far less looks from some ninety-year-old senior citizens than I do. And I can tell you that it is not really flattering when somebody has to look over the dash to be able to see me, and, you know, then just about rear-ends me. But that's another story for another day. But, you're right, that when I went out and looked for it, I had some ideas. And if I would have just gone and, you know, browsed the whole gamut, I might have ended up buying a Hum-Vee which, that's not gonna do my...the stuff that I need to do. So, when we're talking about a tool, we have got a compatability issue that you talked about. We've got the tool audience. What about budget constraints? Does that come in now or does that come in later?

ELISABETH: Well, now is a really good time to understand your budget. So, taking the sports car analogy, there is going to be a huge difference between the high-end Porsche and...and whatever the lowest-end, say Mazda two-seater, is. Right? In terms of price.

CAROL: Right.

ELISABETH: So you had better know what your budget ranges, even if you don't have an absolute budget defined yet, so that you know what you can afford.

CAROL: Right. And...and can that be something like...what if you don't have a budget and somebody says, "Go out and evaluate some tools, and I want you to bring back and evaluate for sixty days two of the best tools that will meet A, B and C. And they don't give you a budget. What would you advise to those people?

ELISABETH: In that situation, I always ask a hypothetical budget question. So, I say to that person, "Okay, fabulous. Imagine that I have found the perfect tool for us and it is going to cost us a million dollars. Are you going to be able to approve that expense?" And they usually turn all kinds of shades of white and say, "No." And...and, but not necessarily. It's just in my experience they've always said, "No, not quite. And so, okay, well...well why don't we try half a million. Oh, not that, okay." And so through this process of kind of dividing by half, we get to the range where they are not turning all kinds of shades of pale, they're just wincing.

CAROL: Right.

ELISABETH: And that's where the point where I know we are at least in the ballpark. "So, I don't know, I don't have an exact figure, and I don't know if I'm going to be able to get permission, but at least I've got a range."

CAROL: Right.

ELISABETH: And so that allows me to not waste anybody's time with evaluating tools that are going to be way out of my range.

CAROL: And that's a good point. Because, I think oftentimes our eyes are bigger than our stomachs, so to speak, that we get this wide-eyed, "Wow, this would so incredible to have, and yet we may never actually be able to afford it."

ELISABETH: That's right.

CAROL: Now, one of the other things that I thought was really interesting but I think gets overlooked a lot, is something that you said as well, which is sometimes there is additional corporate requirements. That you're evaluating a tool, you've got your requirements, you've laid it out, you've got your budget, and you've gone through everything. And I think that this...this piece that is up front in your article needs to be, because it is...what about approved suppliers?

ELISABETH: That's right. If you are working in an organization where the Purchasing Department has a large amount of control over who you get to buy stuff from, then you either need to go with the already existing approved list of suppliers, or start the process early of making sure that...that the vendors that are on your list can...can begin the process of becoming an approved supplier.

CAROL: And we'll be back with more of Elisabeth Hendrickson and talking about how to evaluate tools after these short messages. We're back to show number seven. We've been talking to Elisabeth Hendrickson, who is a Senior Consultant and who has recently returned to private consulting. She started up a company called Quality Tree Software, and we have been talking to her about the method, a structured method, to go out and evaluate a software tool, whether it is a test automation tool, whether it is a new piece of software that your company needs to solve some problems. And we've gone through her first step, which is really called, "Defining Your Initial Requirements." And I think too often, what would you say, ELISABETH, how often in a percentage-wise basis do people actually start with that first step and get...get the initial requirements actually documented.

ELISABETH: I think it is pretty rare, and I think that that's unfortunate. My experience is the times I have done that it has been a much more successful process. I think that most often folks start with a shopping phase. They'll...um, decide that they are going out and find all of the vendors, and then they become overwhelmed by the number of possible choices and end up going back and doing step 1 after spending a fair amount of time in step 2, and then they have to go back and do step 2 again.

CAROL: Well, and, I think that comes naturally because with, you know, technical backgrounds we like the glitz, we like the glamour, we like the bells and whistles, and English and writing is not necessarily our first passion.

ELISABETH: True, very true. But remember, you don't have to document these to a tremendous level of detail. In fact, I think that you do yourself a disservice, if for a tool you end up with a 50-page specification of what you want the vendor to supply.

CAROL: And, particularly, if there is nothing that is even going to meet those needs.

ELISABETH: That's true. So, I focus on checklists, I focus on brief, not necessarily even complete sentences, to describe what it is I need this to do, and lots of pictures.

CAROL: Now, once you do that, do you pass it around to everybody at this stage, say all of your potential users, to actually take a look at this or give you fog test.

ELISABETH: I do pass it around. I don't necessarily pass it around to everyone who will ultimately be involved in the process, because at this point I don't want to get people involved too early if they aren't going to really be part of the decision process.

CAROL: You could end up with the analysis paralysis.

ELISABETH: Absolutely. So, yes, I need feedback, and so the folks who are going to be using the tool on a day-to-day basis or who need to get information out of the tool, like management frequently needs to get reports or status information out of a tool. Those are the folks who I am going to run it by first. And, also, I am going to get at this point...I am going to get a champion, if I don't already have one, I probably do, but I'm going to line up my champions at the executive level who are going to be able to approve the budget. I am going to have the budget for the tool and plus I am also going to have expenses for training. And I'm going to have to have their buy-in that this is a good way for us to use our time.

CAROL: Now, would you expect to find a champion, even for say a ten-thousand dollar software tool.

ELISABETH: Oh, absolutely. Ten-thousand dollars is still a lot of money in a lot of companies, and, so, if I'm at a management level and don't have that kind of authority to bring in that kind of tool, I definitely need to get a champion. I may discover unfortunately that my purchase order gets rejected by...during the purchase order process much to my surprise, just when I most need the tool.

CAROL: Right. Now, what's the budget. You were talking about setting up a budget. Should I be including things like the perceived or the potential cost of training people, you know, needing the vendor's support. Do I need to factor that into the original budget.

ELISABETH: You need to take it into account how precise and how formal your budgeting process is, is going to determine whether you actually create a spreadsheet that has all of these line items in it and the anticipated month or quarter in which you are going to send this money, and so forth. What you may end up with is a sketch on the back of a napkin or whiteboard somewhere that says, "Okay, um, Janice, Miss V.P. - Here's the...the costs…the licensing costs are going to be this much and we are going to have to bring in some consultants to help train us on this tool to make us more effective on it, and it is going to be about this much, and so it may be that informal but, if you don't take it into account up front, all of a sudden you are going to discover there is no money for training. And so you have this lovely, powerful, extremely wonderful tool that you've spent an enormous amount of time selecting and you don't have the outside help to help get your department up to speed to use it most effectively.

CAROL: And that can cost more than the actual tool itself?

ELISABETH: It can. It depends on how much consulting. Frequently with tools, what you'll find is there is the training class that you can send your folks to, and that will be like a two or three day training class. And that's...that's compared to the price of the tool, you probably won't spend more on that than you spent getting the tool. However, if you need to bring in consultants to help customize what you're learning to your actual situation, you can end up spending up a lot more on those services than you did on the original licensing fees for the tool. And at the same time, it can be very worth it, because it saves you a huge amount of...if time is money in business, it saves you huge amounts of money in false starts and things becoming shelf-ware.

CAROL: I absolutely agree with that. We've got our step 1, we've defined our initial requirements, we've got a budget, we've got some ideas, and now we move to step 2, "Investigating Our Options." We will go through steps 2, 3, 4, and 5 when we get back with more of Elisabeth Hendrickson, talking about evaluating software tools. And if you're just joining us for this second half of show number seven, "Welcome to our listening audience." I have been speaking this week to Elisabeth Hendrickson, who is the founder and President of Quality Tree Software, Inc., and she also has a Web site called, the Quality Tree Web site, which is at www.qualitytree.com. I am Carol Dekkers. I am the President of Quality Plus Technologies and our web site, who many of you may be listening to the show through, is www.qualityplustech.com.

Elisabeth, welcome back to the show. We've been talking about evaluating software tools, and we've gone through all the requirements and spent a little bit of time talking about that. The next step, "Investigating Your Options." What can you tell us about investigating options?

ELISABETH: Well, so this is...you already know what you want the tool to do. And this is the point at which you get to go shopping. You get to go search the Web, ask your friends, ask other departments in the company if they have a solution for a similar problem. You get to go to conferences and hear both...see the vendor presentations and also hear about how other companies have implemented similar kinds of tools, what they chose, and what their selection process was. And from all of these activities, what you come up with is a list of potential suppliers who could give you what you want.

CAROL: Interesting. And...and, so you actually go to a vendor show, or you go and you search the Web, or you go to a conference, and you take your shopping list with you.

ELISABETH: That's right. And you also take your list of requirements with you. So, this is the other reason you don't want a fifty-page document for your requirements, because you are going to end up actually showing parts of it to the vendors to ask them, "Is your tool even in the ballpark of what I need to do?"

CAROL: And that's a really good point, because, otherwise, I've seen a lot of times people go to trade shows and the vendor runs the show. The vendor says, "Here's what you need and here's how I can solve it," and it may not be what you need at all.

ELISABETH: Well, yes, and with all due respect to the vendors, they can't possibly know what problem you personally are trying to solve. They know a lot about problems in general, but they don't know anything yet about your software.

CAROL: I guess that goes back to the car dealership. If you walk in and you don't tell somebody that you need to have, you know, you need to shuttle six kids to and from soccer practice, they're going to steer over to the Porsches, and the things that will kind of get your eye.

ELISABETH: Sure.

CAROL: So, I think that kind of fits in. Now, when you do this shopping, are there certain things that you should watch for, certain things that you should ask?

ELISABETH: Sure. Well, first of all, what you want to watch for is not...you can pretty much ignore the slick marketing stuff, and I'm really sorry to the tool vendors that have invested a huge amount of time and money in their slick marketing stuff. But, what you really want to pick out of that information is look for matches between what they advertise that their tool can do and the items that are on your list. And then the other thing you want to do is actually talk to somebody from the company, and you want to find out, "How can I compare your product with other similar-looking products on the market? Help me understand what differentiates your product. Help me understand the situation in which your tool is the best choice. When is your tool maybe not a good choice? Are there situations in which maybe this isn't going to be a good match?" And one of the questions that I like to ask that they don't like to answer, is I'll ask the salesperson, "What don't you like about your tool?"

CAROL: Oh, that's interesting. And are they honest? Will they actually come out with forthright answers that say, "You know, I wish it did this?"

ELISABETH: Well, there is a big difference between honest and tactful, or rather, they can be honest and be tactful. So, I've never ever had a salesperson who disparaged their own product, but they'll...they'll...they'll answer, but they'll answer in an extremely tactful way. Like the interview question where you asked, "What's...if you have any weaknesses, what might they be?"

CAROL: Right. And I guess it's similar...we go to restaurants and we'll say, "Should I order this or this, or how is such and such?" And when the waitress hesitates, you already know.

ELISABETH: Right.

CAROL: So, if somebody says, "If you were building the tool today, or if you got to choose and run the company, would you do something different?" And as they kind of pause, you know that they're probably thinking about a number of things they would do differently.

ELISABETH: Right. And your goal here isn't to put the salesperson or the representative on the hot seat; it's not to humiliate them, or embarrass them, or embarrass the company. Your goal is to see if you can get additional information that is going to help you decide whether it makes sense for this to go on to the next phase.

CAROL: And it may be that the tool has things in it, or there may be things coming up, or there may be flexibility to customize the tool that might be something you'd never find out otherwise.

ELISABETH: That's right.

CAROL: Now, once you've done the shopping, you've gone and you've gathered the shopping trip information, you recommend that we do step 3, which is "Refine Your Requirements." Is that kind of aligning what you found out on your shopping trip with your original requirements again?

ELISABETH: Absolutely! Because what you are going to find is that perhaps you...the wish list that you have there is just is no tool that is even going to come close to it, and maybe it's time to reconsider what you want it to do, or maybe you are going to find that you were too modest in your expectations. And there's a lot of great stuff out there that you can make good use of, and now that you know it is available, you can go back and determine how you would apply that in your environment.

CAROL: Now, is there a danger when you are at this point of going in and adding in wants instead of needs?

ELISABETH: Sure. But I don't consider that a danger. I actually consider that a good thing. Because when you get to the evaluation part, you are going to have to be able to make a decision about which tool is going to best meet your needs. And sometimes that comes down to wants. So, as long as in your checklist you have a clear distinction between, "We absolutely need these features, these capabilities. If we don't have them, we don't have a solution at all." And then there is the wish list. The...the...the "It would be nice to or it would be really good if..., or we could make a lot better use of this tool if..."

CAROL: And...and I think that is something we didn't really mention when we were talking about the business requirements, about the initial requirements, is really identifying which ones are the critical, cannot live without ones, and the ones that are, "Yeah, this would be great, I'd kind of like to have this," but it's not a deal breaker.

ELISABETH: Right. Identifying your deal breakers is critical.

CAROL: And those would be the ones that are absolutely critical.

ELISABETH: Yep.

CAROL: So, once you've refined your requirements, you'd advise us to narrow the list. And that is really when you start ranking them.

ELISABETH: That's right. Because, now, sometimes you get to refine the requirements and you discover there's one less that meets your needs...Okay, you're done. If you chose to go ahead and purchase a tool to do this, and that's always another choice, which is "Well, maybe we decided that we don't need anything right now at all." But, if you decide to go ahead and purchase, if you're down to one choice that meets your must have requirements, then you're done. More likely, though, you're gonna have several that could potentially meet all or some of your requirements, and so now is the time to figure out which is going to be a best fit with all of our requirements, or our capability requirements, what does it need to do, and also our budget requirement.

CAROL: And I really like the way that you have put together in the article itself on how to rank priorities. I'd just like to walk through them. You said a face-to-face meeting is a good form for prioritization. And if you can't find a tool that meets all of your requirements, you will need to prioritize the requirements, so that you can choose the tool that is the best fit. And you put together five steps that says, "Number one, invite in everyone with a say in the tool selection decision. Number two, post a list of the requirements, print it large enough to be read from a distance on the wall or whiteboard. Number three, everyone at the meeting gets three votes. Four, each person may cast his or her votes in any combination, one at a time, or multiple votes, for a particularly important requirement. And number five, tally the votes up, and now the requirements are now prioritized. I think it is very interesting to use three votes, because I think in most cases people would say, "You get one vote, and by the way it better be the same as my vote."

ELISABETH: Well, that's a way to ensure that the selection process is dictated rather than ensuring that it meets the business requirement.

CAROL: How does it work when you have...when you use these three votes. Are people...that's got to be a new concept.

ELISABETH: Actually, I find it...it was several years ago and now I don't find that it is. And so I don't know if that means that more and more people are using this style of multi-voting, or if that means that I am just in a different, you know, it just happens that the organizations that I have been working with have used this before.

CAROL: Have you only been working in Florida lately?

ELISABETH: No, I've been working primarily in California.

CAROL: Okay. That's a joke to do with our voting process down here.

ELISABETH: Oh...I'm being dense, I'm sorry.

CAROL: Because, you know, if we don't vote the way that we wanted to the first time, we might get a second chance or...

ELISABETH: That's right...

CAROL: Or maybe a third chance.

ELISABETH: And dimple your ballot.

CAROL: We're not going there. I know that Chad Everett is still pretty upset that he wasn't counted twice. But, once you've got these priorities and you've actually stepped through this, your last step that you advise is to evaluate the final list.

ELISABETH: Right. And that's where you actually bring it in, hands on, and make sure it is going to work in your environment.

CAROL: Now, what would you say if a vendor...and I have encountered these, if a vendor will not let you evaluate a tool, they insist on an investment.

ELISABETH: Uh huh.

CAROL: And you have to essentially pay for the tool before you are actually allowed to see it. I know that when I was in development advising one of my clients, they wanted to look at the types of reports that were produced by a particular tool. And the tool vendor said, "You can't find out what the reports are unless you sign nondisclosure, and you can't use that in your comparisons."

ELISABETH: What do you mean you can't use that in your comparisons?

CAROL: Well, they would not allow the list of their reports to be published, even internally. So, it...

ELISABETH: Oh.

CAROL: It is kind of a dysfunctional situation.

ELISABETH: Well, and you know that tells you something about how your relationship with that vendor is going to be later.

CAROL: That's a good point. And we'll be back to finalize everything and sum up after these short messages. I'm Carol Dekkers, and we've spending the last good portion of an hour talking to Elisabeth Hendrickson about how to evaluate tools. She has come up with a very good step-wise process. Number one, we went through, "Defining Initial Requirements." Number two, we walked through, "Investigating Options." Number three, "Refining Those Requirements." And, as you said, "Sometimes there is only one tool that meets the needs, so you don't even have to do step four and five in that case. Or at least step four. " Four is, "Narrowing the List Down by Priorities." And number five is where we were at, which is, "Evaluating the Final List, Bring in the Tool Vendors," and really, I guess, "Test Driving the Software."

ELISABETH: That's right.

CAROL: So, at the end of this, then hopefully your requirements are going to be good, that you'll end up, you've decided on a tool, and is that the end of it? You decide on the tool, you write the check, and you're done.

ELISABETH: Yeah. Well, no, you have to implement, and that can take a fair amount of time all by itself.

CAROL: And what does that mean? For listeners who have already thought, "Oh my gosh, there's so much involved in a getting a tool, I've written the check, I bring it into my office, and now I have to do more stuff?"

ELISABETH: Well, yes, because now the tool, you have to make use of the tool in your environment. And that means that you need to actually begin to apply it to the problems that you brought it in to solve. Usually that involves some design work and some planning work, and actually sitting down at a keyboard and integrating it all together

CAROL: So I'm not quite finished there, but now I actually get to use it and play with it, and start making it a part of my everyday life at work. One thing I find kind of interesting is that one of the things I see overlooked, especially when the user community is involved, sometimes they want a tool for the way they want to do business.

ELISABETH: Um huh.

CAROL: And, so they give you all the requirements, and the software group goes and works with the users, and you find the tool that is going to be perfect for the way that they want to do business. And then the user community forgets that they need to change the way they are doing business, so that this tool will fit in.

ELISABETH: Yes, and that can mean some interesting times in changing...if you bring in a tool that you expect is going to...you're gonna have to change the way that you do business in order to implement it, you've got some change management issues there. And that can involve fear, because people don't want to change the way that they are working, they are afraid that their job is going to be eliminated, they are afraid that they are going to be no longer qualified to do their job, because maybe they don't know how to use the tool and they don't know how they are going to learn how to use the tool. And so you have to manage that...that fear of change, and you also have to have a vision for what the organization is going to look like after the change.

CAROL: So, this whole process is a lot more than just going out and buying an off-the-shelf package, which, I think, too many people haven't even realized yet. They are still in the mode of, "Let's go out and buy a package," and they are probably like my office. They've gotten...you know, when I go to Office Depot and I buy something, I get like four free software packages and they line my shelf. I've seen stock rooms in large corporations that have all sorts of software. It almost could be a used software room.

ELISABETH: That's right. And those are unfortunately the carcasses of efforts where it only went part way.

CAROL: So, your method really gives them a chance at success, a chance where the software tool is really going to be a good investment.

ELISABETH: That's right. And that has been my experience, that when you go through all of these steps you end up actually using the tool instead of putting it away on a shelf.

CAROL: And then the tool does exactly what it is...as a tool. I think sometimes, you know, when we go shopping for a hammer we know what it's supposed to do, and a tool should be just that, it should be something that makes your life easier.

ELISABETH: That's right. It's not an end in and of itself.

CAROL: And I thank you. I think this has been a wonderful hour. I think that you've imparted a lot of information. And we are both at the Paradise Point Resort this week at the Applications of Software Measurement and the Software Management Conference in San Diego, which runs all this week. And if anybody would like to come down, if you're in the San Diego area, if you would like to come down and meet us in person, meet Elisabeth Hendrickson and Carol Dekkers in person, you can actually obtain a free Expo Pass, where you could try the very things that Elisabeth talked about today. You can come down, join us; all you have to do is go to the Paradise Point Resort in San Diego, and any time that you are there between now and 3:45 p.m. you can pick up a free Expo Pass at the Registration Booth there. Elisabeth, thank you for joining me. This has been a wonderful hour, and as I said, we just keep getting cream of the crop guests.

ELISABETH: Well, thank you very much, Carol. If there's a moment, I would also like to mention there is a Test Automation Conference coming to San Jose March 5th to the 8th. And to get more...you can also get into that Expo, that's March 6th through the 8th, and for more information on that visit SQE's Web site.

CAROL: Great. Well, I thank you and I hope you have a wonderful rest of your day. I will see you a little bit later as we are both in San Diego. Thank you very much.

ELISABETH: Great. Thank you. Bye-bye.

CAROL: And we'll be back with more of Quality Plus E-Talk and summing up after these short messages. Welcome back to Quality Plus e-Talk. I'm Carol Dekkers, and as we mentioned before we went into our final break, Elisabeth Hendrickson and myself are today, February 15, at the San Diego Paradise Point Resort at the Applications of Software Measurement and Software Management Conference. If you're interested in actually trying what Elisabeth mentioned, which is coming up with a set of requirements, going shopping, there is a perfect shopping opportunity for you if you're interested in measurement tools, if you're interested in software management tools. I'll be there, Elisabeth will be there, and a cast of probably about 800 people will be there. But we would love to have you come by, stop by my booth, which is Quality Plus Technologies, come by and say that you're a listener of the show. I'd love to meet you in person. Elisabeth will be doing a presentation. I'll be doing a presentation today right around lunch hour, I don't have the time sitting right in front of me, but I'm going to be doing a presentation on Extreme Programming Meets Measurement, which was the topic of our show two weeks ago.

Now, we've got an exciting line up coming up of shows in the next few weeks. You can go to www.qualityplustech.com and you can actually pull down the radio show season schedule. We've got everything filled out now, except for the final show, which is...we are going to leave you in suspense because we've got some excellent guests that we are lining up for that last show. Coming up next week is Tom DeMarco, the person that everybody has been waiting for. And I feel absolutely flattered that he would spend the time with us. He is going to talk about risk management, making success possible. And as I mentioned on the show last week, I'm also gonna ask him, we'll do a little segue into his new venture, which is publishing fiction. And he has just written a book called, "Dark Harbor House" which has just been released, and will probably soon on the New York Times Bestseller List. So Tom DeMarco of the Atlantic Systems Guild will be here next week, the week after we have David Zubrow, who is a senior member of the technical staff with the Software Engineering Institute, and he'll be talking about advanced maturity. And we're not talking about advanced personal maturity, we're talking about advanced corporate maturity, in terms of the capability maturity model integrations model, and we are going to be talking to him about what he has seen worldwide, because he will be fresh back from the Software Engineering Process Group, SEPG Conference, in India that week.

March 8, we have Al Davis, who is going to be talking about requirements management and Internet time. So, he is an IEEE Editor, Chief Editor emeritus. Did I say that properly? He has a litany of credits to his name, and he is going to be talking about, "What can we do about requirements management in Internet time?" Jim Highsmith will join us March 15th. He is going to be talking about adaptive software development, lightweight methods, for the new millennium. And March 22 we have a treat for you. We have Software Standards, process standards, in lay person's terms, "Taming Your Process With Standards." What should you do to choose a standard that might fit with your organization. Stan Magee, who is part of the U.S. Technical Advisory Group to ISO, and Peter Voldner, who is part of the Canadian delegation to ISO, will both be with us on that date to talk about what you should look for in ISO standards.

I thank you very much for joining us this week for Quality Plus e-Talk. It has been a wonderful time to have a listening audience. Keep listening to us, learning things, as we grow together and build better software. I will e-Talk to you next week with Tom DeMarco. Thank you for joining us. Have a great week.

Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.