| I've just read a great article «Evaluating | | | | 3rd Pitfall: SaaS is ever evolving |
| vendors? Kill the spreadsheets » by Alan | | | | When buying SaaS, a list of questions will result in a |
| Pelz-Sharpe from Intelligent-Enterprise. | | | | snapshot of the current product. As SaaS products |
| So what's he talking about? | | | | are delivered over the internet, they can be updated |
| Well, decision makers and IT procurers usually follow a | | | | seamlessly whenever the developer has built a new |
| standard process for buying software: | | | | feature. For this reason, buyers must know not only |
| 1 - They establish the specification required and | | | | where the product is, but where it is going. |
| construct the famous "table of evaluation." This is | | | | Our Experience |
| usually a Excel file with several sheets and hundreds | | | | We recently received exactly this type of tabular |
| of questions (if not thousands), most of which are | | | | software scoresheet for a huge global BI project. In |
| closed and very precise. | | | | accordance with our SaaS philosophy of selling people |
| 2 - They send the list of questions to a selection of | | | | what they want and only what they want, we were |
| developers (often just the famous ones that come to | | | | strict with our response. Despite not fulfilling their |
| mind straightaway). | | | | requirement completely, we were short listed alongside |
| 3 - The software is scored against the technical | | | | several on-premises solutions. |
| requirements and the top couple of applications tested | | | | Why? |
| before purchase. | | | | Because the buyer could quickly and easily trial our |
| So, what's wrong with that? | | | | application. He set up a demo account and had a go |
| 1st pitfall: many questions leave room for vendor | | | | himself to see how easily it was to use. We then gave |
| subjectivity | | | | a demonstration using his own data and showed all of |
| Lots of answers are very difficult to verify and so | | | | the features he was interested in. We answered his |
| liberal interpretations are only discovered after the | | | | questions live during the demo and every time he |
| software has been installed. Furthermore Alan | | | | asked about a capability, we showed it to him. |
| Pelz-Sharpe reports that vendors will often out right lie, | | | | This was miles away from the formal question sheet |
| skewing the results towards the less ethical developer. | | | | but he came away knowing exactly what he was |
| This leaves the honest and rigorous providers at the | | | | buying and we gained more insight into how our |
| bottom of the pile, even when their software might | | | | customers use our product. |
| actually be the most apt. | | | | So what do we recommend? |
| 2nd Pitfall: technical capacity vs. actual use | | | | Showing rather than telling. |
| Often buyers ask "does the tool do this?" Alan argues | | | | The buyer should test the solution themselves, |
| that a better question is "how can I do this with the | | | | preferably on their own at first and with a |
| tool?" The success of a technology project rests upon | | | | demonstration afterwards. Vendors should always |
| the uptake and adoption by the end users. If a feature | | | | make their products easily available for testing to avoid |
| is technically possible but requires advanced training, | | | | both parties wasting time. Like all good information |
| then it's probably not going to be used and not worth | | | | exchanges, procurement should be a discussion, not |
| having for most users. Ease of use should be as | | | | just a request for information. |
| prominent in the buying decision as number of features. | | | | |