OT: PIM Software Support and Responsiveness

Posted by Slartibartfarst
Jun 10, 2015 at 08:13 AM

@PIMfan: As a fellow PIM fan and a CRIMPer, I must say that whilst I can empathise with your views expressed here, I would suggest that the supplier might have a different view.
Having been a technical/mathematical software developer for some years, and later having managed teams of software developers for large commercial banking/finance systems, and having been involved in many software and hardware buying decisions, and having studied and used many different PIMs and information management tools, I have probably seen all angles of good and bad software development and support.
From experience, the frequency of good development combined with good support is “peaky” - a bit like the Manhattan skyline - some outstandingly tall examples, but most being closer to the mediocre.
. Thus the discussion regarding post-sales QOS (Quality of Service/Support) in this thread is something I am pretty familiar with. The ROT (Rule-Of-Thumb that I have learned to apply is that purchase of software needs to be made on a rational business basis (a business case) - including whether it meets the documented prioritised business requirements in terms of :
A - Mandatory functionality. (Things that it absolutely must be able to do - the must-have critical functionality.)
B - Highly desirable functionality. (Things that we would also very much like it to be able to do, but which are not considered to be critical.)
C - Nice-to-have functionality. (We can live without it being able to do these non-critical things.)

Then there’s the cost. A buying decision typically necessitate compromise and trade-offs regarding prioritised business requirements.

Now, IF post-sales support with a high QOS is an “A” priority requirement, then the usual practice is to pay an annual maintenance fee for that, and that would typically be factored into the contracted price to buy/use the software.
However, if the requirement for post-sales support is an “A” priority requirement, then the buyer would need to establish what they expected to be getting for that, and WHY it was necessary in their view, and whether the supplier was able to contractually commit to delivering on that.

Let’s extend this ROT into the selection of PIM (Personal Information Management) software, and see what we might get:
(a) Prioritised business requirements:
We will probably have no idea as to what is A, B, or C, as these will have probably not been defined and documented in terms of detailed functionality and communicated to the supplier as such. However, depending on the buyers’ level of experience, the buyers would probably (usually) have - in their heads ay least - an idea of the features they want and the expected look-and-feel and ergonomics of the UI (User Interface). In any event, it would be unlikely that post-sales support with a high QOS would have been factored into our requirements, otherwise we would have established whether that was an A, B, or C requirement at the outset, and whether the supplier was capable of meeting that particular requirement - before buying.

(b) Price: We probably want it FREE - or at least, costing ALAP (As Little As Possible) - this is for personal use, after all, and we are not all made of money.

Whilst one might become indignant at a diminishing level of interested responses from the supplier as our communication of suggested new features or of faults found continues, one should not be surprised. It would not be correct to call this a poor service response from the supplier (even though we might consider it so), if a higher QOS was not proclaimed as being a mandatory requirement and one that could/would be met by the supplier AT THE OUTSET.
Insisting in the face of this that the supplier is morally bound to respond as we belatedly expected them to, or something, is rather like trying to write new terms into the contract AFTER it has been agreed to and performance has been engaged.
In a typical PIM case - with the exception of, for example (say) Microsoft OneNote - the supplier probably would not be able to cost-justify having the resources necessary to support “high maintenance” customers asking/making lots of points like that, and was thus - in your case - probably only trying to be polite with their initial responses, and then regressed to the mean (or whatever they could sustain) after that. You might even have become a persistent nuisance in their view.

Though you do not give the supplier’s name, I suspect that (if not already done) if you did them the courtesy of showing them a link to this discussion, then they might agree that what I had written here was more or less the case and might even choose the right of reply to confirm their situation. They would probably also realise that this could be an excellent forum for discussion about the pros and cons of various PIMs, including their own - if they did not want or could not cost-justify setting up such a user group forum for their product.

On the subject of User Group Forums, there is a school of thought that, as a matter of policy, whilst they should support user forums, these should never be controlled/governed BY the service/product supplier, as that would usually not necessarily meet the needs of the users. For example, this is/was a policy adopted years ago by Hewlett-Packard for its vast range of hardware and software, and I personally sat on the committee of one user group where we steadfastly kept the group at arm’s length from the supplier organisation, and funded it through user member organisations, so as to retain our financial independence and integrity.

There is a classic example of a supplier failing to adopt this policy and of what could happen then, in the case of the excellent PIM software InfoSelect. The IS Yahoo! User Group forum had rather been neglected and fallen into disuse and had no leadership. Then the IS developer (Jim Lewis, CEO of Miclog.com) announced that he had taken over the vacant role of owner/moderator, and promptly announced an imminent Beta version of IS10 and wanted people’s feedback and *requirements* - and then proceeded to apparently ignore the latter. As matters proceeded (you can read about it in this forum too), it became what must have been a signal embarrassment to the developer and arguably a gross public fiasco, with some users even spitting the dummy, announcing they were switching to other PIMs, or even leaving to set up an independent user group as they saw how their forum had been taken over and seemingly abused.
The developer (Jim Lewis) even seemed to abandon the forum after that, only venturing back unapologetically recently after an extended and unexplained absence to announce a potential new version - IS11 - which announcement seems to have gone down like the proverbial lead balloon and met with an underhwelming response from users who had been so disappointed by the IS10 fiasco.