I am in the process of investigating best practice methodologies on software package selection and would be interested to hear from members of the ganthead.com community the following. First, where do you recommend I search for public information (white papers, articles) on the subject? Second, do you have specific feedback or examples of pitfalls and lessons learned?
I would appreciate any feedback you can offer. Saving Changes...
Sort By:
Stephen MayeSenior Vice PresidentVa, United States
As far as lessons learned and best practices, I've seen a few things that are probably worthy of mention.
First, approach the selection from a negative perspective. This means that you should be looking for reasons to throw vendors out rather than keep them in. Ideally, you want to be looking at 3-5 RFP responses, not 35. (I worked with a customer a couple of years ago that had to review 27 responses to one of their package selection projects. A simple vendor focused filter applied at the beginning of the process would have likely saved them a lot of time [i.e., money]). To do this well, you have to avoid a detailed evaluation of the software until you are comfortable that these are vendors you are interested in working with.
So, get a quick long-list of packages based on general fit, not a detailed evaluation, until you have looked at the vendor. (I know of an ongoing selection project--right now--where the customer selecting the software was completely sold on the software package and then found out that the vendors country of ownership was in conflict with company policy. Much of the time spent evaluating the package was wasted. Summary: Be negative and use a coarse filter to weed out the vendors before spending a lot of time on the software. It will save you a lot of time and money in the end.
Get a lot of the consensus building out of the way before people are dazzled by the demos. This means that you need to take a structured, principle-based approach to the evaluation. If you have a clear set of weighted principles and criteria--derived from not only the funtional requirements of the application, but also reflecting your enterprise architecture standards (or equivalent), you will reach a decision with much less controversy. You don't want the process to be too subjective (based on the opinions of those involved). Get agreement on way the package will be selected and the actual selecting will be much less painful.
These ideas are made much more tangible by the gantthead package selection process (available on the site in the process section on the front page). It really is one of the most practical and easy to apply "development" processes that I'm aware of (including the other gantthead processes ;-) )
I hope this helps! Saving Changes...
Matt TenchExperienced Project & Programme Manager| FreelanceGeneva, Switzerland
