This is a series of posts on the subject of when an organization decides to drop the support for a previous version of a software. Say, you are working on version 8 of a software and version 4 was released 4 years back, and the management team is trying to make a decision on retaining support for the software version. In a previous post (Supporting previous versions of the software (Part 3)), we had talked about a situation where there is no choice but to drop support, because of a dependency issue. The previous version used a software component that is not working properly and there is no way to fix this; in many such cases, the organization has to take action. It cannot pretend that the previous version is working fine except for a few glitches, and instead would need to declare that the version is no longer supported. When it says that a version is no longer supported, it actually means that there will be no support, no updates, no bug fixes and it is recommended that users upgrade to a newer version of the software.
What happens in the case where the organization has no data metrics about the number of users who are using the previous version of the software. Well, it does get kind of tricky, but these situations have happened in the past. The emphasis on being able to trap user interaction and mine this data for doing all sorts of analysis (including determining usage habits) is something that is of relatively recent vintage, not being emphasized even 4-5 years back. Now, every product tries to capture user interactions, which workflows use more often, and so on; but consider the case when this data was not being tracked and now the organization wants to drop support for a previous version of the software for which they do not have this kind of data.
Just because they do not have this data does not mean that the organization will continue to support previous versions for a long time. There is an increasing heavy cost associated with supporting long back previously released versions of software and at some point, the organization will decide to drop support. If there is no user data, the organization could check with support teams and with user support forums about the amount of queries that come in for these previous versions of the software, and if it seems that there are a large number of users that are active for those versions, then it makes sense to not drop support for some more time. On the other hand, if it turns out that there is hardly any interaction related to that specific version, then it might make sense to take the decision to drop support. Of course, there is some amount of subjectivity involved in this, since forums might not be a totally accurate mechanism to determine whether there are a lot of people using that version, but it is a hard choice. You have no other mechanism to determine the usage levels and you have to use some kind of proxy to help you make that decision.
One way is to make announcement about dropping support in another few months, and then see the reaction. If there are a large number of people who voice complaints and so on, then it might make sense to interact with some of them and determine whether they are really discomfited if support is dropped, how often do they really need some kind of support and so on. Even in such cases, after due discussions and interactions, it may still be possible to drop support (even if there some amount of opposition, as long as it is containable).
What happens in the case where the organization has no data metrics about the number of users who are using the previous version of the software. Well, it does get kind of tricky, but these situations have happened in the past. The emphasis on being able to trap user interaction and mine this data for doing all sorts of analysis (including determining usage habits) is something that is of relatively recent vintage, not being emphasized even 4-5 years back. Now, every product tries to capture user interactions, which workflows use more often, and so on; but consider the case when this data was not being tracked and now the organization wants to drop support for a previous version of the software for which they do not have this kind of data.
Just because they do not have this data does not mean that the organization will continue to support previous versions for a long time. There is an increasing heavy cost associated with supporting long back previously released versions of software and at some point, the organization will decide to drop support. If there is no user data, the organization could check with support teams and with user support forums about the amount of queries that come in for these previous versions of the software, and if it seems that there are a large number of users that are active for those versions, then it makes sense to not drop support for some more time. On the other hand, if it turns out that there is hardly any interaction related to that specific version, then it might make sense to take the decision to drop support. Of course, there is some amount of subjectivity involved in this, since forums might not be a totally accurate mechanism to determine whether there are a lot of people using that version, but it is a hard choice. You have no other mechanism to determine the usage levels and you have to use some kind of proxy to help you make that decision.
One way is to make announcement about dropping support in another few months, and then see the reaction. If there are a large number of people who voice complaints and so on, then it might make sense to interact with some of them and determine whether they are really discomfited if support is dropped, how often do they really need some kind of support and so on. Even in such cases, after due discussions and interactions, it may still be possible to drop support (even if there some amount of opposition, as long as it is containable).
No comments:
Post a Comment