e-Talk Radio: Hendrickson, Elisabeth, 15 February 2001

Rebroadcast 29 March 2001

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

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.