tool_evaluation

software tool evaluation This question is in a format common to our industry: why one software tool over another? In a past life as a software development management consultant I was often asked to do tool recommendation. Detlef mentioned the important component, personal taste. However, if you are in a position where your recommendation will fire off a string of purchase orders, personal taste can seem too subjective. You need a method of justifying your decision. I found myself using a handy tool both to select, then present my decision. It is fast, as objective as such a decision ever could be, deals with the component of cost benefit ratios. Build a table (I use excel). Across the top, make columns for each brand of software you will consider. In this case Toolbook, Director, Authorware, MTropolis ... and any others you or your management may be considering. Now go to the web pages for each of these tools, or, if that is not available, contact the vendor. Get a list of the important features, those which the company itself offers as the reasons you should buy their product over the competition. IF you are speaking with a vendor, tell them you are doing a software eval, they will happily provide you a list. List these down the left most column. Only place a feature in the left column, once. So if Toolbook and Director share a feature,it will only appear in this column once. "Features" that you learned of through soliciting a community of actual users, such as the Direct-L can also be added to this list, but you should group them separately, or flag them somehow, as they are "Anecdotal". Don't forget to include such features as learning curve, ease of use, tutorials or "free" training included, etc. Another very important feature is the platform or hardware it requires to run. Do you already own what is needed to run this tool, or will additional purchases be required? SO, now you have all the main features of the various products in a list. At the foot of the column devoted to each product, put its list price. For each software package, place a zero in the cell for each feature it offers. Now, go back and highlight the rows for features your project actually needs. Replace the zero with a 1 (one) in any cell that is a feature the package has, AND you actually need for your project. If you anticipate using this tool over time, come up with some weighting system, giving higher points to the features you need immediately, lower points to features you definitely anticipate using in the next year. Further out than a year, and the tool will have been upgraded or replaced, affecting over-all cost. Count up the ones, then divide the total cost by the number of features you will definitely need....and you have a cost per feature benefit ratio. (this is why I use excel) The point here is....you can spend a fortune on a race car, but if the speed limit is 55 mph, or the driver will only go 45mph, why spend the money? If you want to get fancy... present two cost-benefit ratios. First count up each significant feature per tool and divide the purchase price, the results is a feature-cost-benefit ratio. THEN count up the features you will actually use in your first project, and divide the purchase price by this second, possibly lower number. Present both numbers.... to furnish material for the inevitable discussion about "well, we might grow into it..." So, this was the 5 minute course in software tools evaluation, which consulting houses get paid the big bucks to make look like rocket science. Put on a fancy blue suit when you make your presentation... maybe your recommendation will be worth the small fortune they ask for ;-) Beth Macdonald