Reading the numbers. So the vetting grid is complete and I feel good about the process, even with a short schedule the results are accurate and compelling. Out of 6 vendors (a 7th didn’t make the cut at the last minute due to a complete lack of preparation for a meeting), 2 were very good choices for my client and had very similar scores. This is where the additional axis of operational efficiency, ease of use, and support of change (which I highlighted at the close of my first post) were useful. Viewing the scores in this context favors the product with a higher ease of use score, a critical factor for creative operations users.
dPOCp. Do a POC Please. This was my strong recommendation to the client as I believe it to be an important step in a software selection project, but my client did not follow this particular path. Here are 3 primary benefits for doing a POC (Proof of Concept). First, you have an opportunity to meet and assess the quality of the people behind the software. Second, if your organization cannot commit and organize the internal resources to support a POC then you are probably not prepared to sucessfully implement new software. And third, assessing the results of actual users performing real tasks closely aligned to their daily responsibilities is paramount to the decision.
This third benefit requires an explanation, which also speaks my definition of a POC. It should be real, actual work getting done by actual users who have committed time away from their full-time role to help your organization assess the software. I don’t believe you need a stopwatch, the users will tell you if it is easier and time-saving or not. However, If the work is a placeholder, and the users are not given time to commit to the POC - then my experience tells me it is not much better than an extended demo and opportunity to meet the vendor team. Significantly less beneficial than a POC. Remember, you are about to put software in place in your operation - something that takes 1/5 the time it takes to remove software from your operation (for another post).
Pick up the phone, or take a ride. I requested each vendors provide my client with at least 3 customer references, and after a nudge or two they did. I also strongly recommended to my client that they invest the time to speak with or meet the references in person. I also reminded my client that these were customers who were currently happy with the software - so plan your questions accordingly. Here are a few examples I provided:
- Where in the project lifecycle is the reference with the software?
- How many users are working with the software, and what role do they have?
- Are the various user roles happy with the software, or must they use it?
- Does the vendor support you with smart people that know how you work?
- Does the vendor nickle-and-dime you when something isn't working?
- Does the reference participate in the user community, if so how?
Dollars and sense. Unfortunately you will need to negotiate a price for the software and professional services. My experience is that you should not leave this blindly up to someone in finance, play a strong role in understanding where the trade-offs and value exist. Unfortunately, this is where my part of the project ended (implementation is the best part!). I believe my client was happy with the results, as this comment notes.
Final words, are you really ready? Success will be found in understanding and managing the operational changes required to meet your objectives - not in the technology itself - even if you selected the best vendor and product for your objectives.
This is the final post of a series of three, please read here for the previous posts, and let me know what you think.
