Help With Sun setting Software - The Project General Company Jakarta

SOFTWARE at END of Life
www.project-general.com 
At some point, every software product will reach its end of life. This refers to the point when a company will no longer support the product moving forward. Each company defines when this happens and what it means for them (and the specific product). It most likely means no further code changes, features, enhancements or bugs.

It’s important to understand that there is a tremendous amount of work that goes into defining and completing an end-of-life cycle; it also requires a skilled program/project manager to successfully accomplish it. It’s important for the PM to understand the reasons for the end-of-life decision; they should also be aware of all the workings of the product(s). This will help ensure that all of the different and necessary stakeholders are involved in the process to successfully sunset the product.

Here are some recommendations to help facilitate this process: 

1. SKUs: Every company that creates a software product has some form to identify it; in most industries, it is referred to as a SKU. This uniquely identifies the product and is used to sell it. This SKU should be removed from all of the various channels where a customer can buy the product.

If the product is direct to the consumer, think about all of the avenues available to the customer for buying it (company website, company store, brick and mortar stores, etc.).
If it is a B2B product, think about removing it from not just the company's website, but also from the websites or sections of partners, re-sellers, ISVs, etc. who may also be selling your product.
A lot of companies also sell bundled products. If this product is part of a software bundle, you need to update/alter the bundle offerings. If the product is available for free, figure out any special steps that need to be taken to achieve the product’s end of life.

Remember, it’s not a quick task to delete a SKU or mark it inactive. You have to understand the impact this has on various systems within the company.

2. Remove it from any "agreement": I use this term broadly to address any type of agreement between the company and the one obtaining the product. Whether it is an end user license agreement or master service agreement, each one needs to be looked into—along with any addendums that may contain references to this product.

3. Privacy policy: There are umbrella privacy policies that cover policies across different products. Sometimes, these are listed by product names. Ensure that the product that you are doing an end of life on is removed from any such documentation. Also, ensure that any effects of removing this product/SKU from the privacy policy are also clearly stated and dealt with.

4. Product downloads: Ensure that the product is removed from any web page that contains links to download it. There should also be messaging indicating that the product download is no longer available because it has reached its end of life. If the software is sold through other channels (like partners, OEM, ISV, etc.), ensure that they are informed and that all links on their download pages are also updated.

5. Additional links: Remove mentions and links of any free offerings—like the ability for a customer to download a free trial, or for the sales organization to create a demo to sell the product (even internally within the company). It should be shelved. If the free trial link is publicly distributed, it should now reflect appropriate messaging with no download links.

6. Sales support: The sales department should be on board with the end-of-life decision. Whether internal or external, the sales department should ensure that it doesn’t sell or even mention this product in any way—it should not be included in any demos, and sales must be aware of how to respond if there is a query for the product from an existing or prospective customer. For existing customers, there should be appropriate messaging and enough timing to direct them to another product. If the product is sold in a bundle, the effects of sunsetting this product must be addressed.

7. Marketing communications need to go out well in advance informing existing customers and/or partners about the product’s end of life. It should clearly state the end of life dates and the end of support dates, and urge customers to move to another solution. Recommending another product may or may not be done depending on company policy, the use case of the product, etc.

8. Extended support: There should be enough time between the announcement of the product going away and the actual end of life for the product. If a customer paid for an extended period of time beyond the end-of-life time frame, there should be an agreement between stakeholders to iron it out.

9. Support teams: Lots of companies have a tiered structure of support teams. All support personnel need to be aware of what it means to end the life and support of the product. There should be knowledge transfers done within the support organization on how to best handle support requests that come in during this period. There must be a solid understanding of how the support team will set expectations for any bug fixes, product enhancement requests, security bugs that are reported, etc.

The end of life should also be appropriately messaged on the support site. If a customer purchased extended support (see above), it must be clear on how that will be handled (whether that support transfers to a new or different product, or there is a partial refund).

10. Technical account manager: If the product is for enterprise customers, they may have the ability to purchase the services of an account manager. Often times, these managers will help the customer with upgrades, ensure that the software runs on different hardware and software configurations, make sure that customers understand use cases, and provide recommendations. Account managers will also work closely with customers on specific bugs or enhancements. If the customer paid for this level of support, there should be a plan on how to best handle it.

11. Professional services: For deployments within the enterprise company—or with customers that are in multiple geographical locations, or with customers who have done heavy customizations with the product—professional services may build on top of the product. This team needs to ready for any end of life process. It should proactively work with its enterprise stakeholders to ensure that a transition is in place. If a customer paid for professional services ahead of time for this software, there should be a clear indication of how that will be handled.

12. Developer community: Often times, there are third parties or developer communities that will build and customize apps. Any communications on public forums, message boards, community spaces, etc. should clearly state the timeline for end of life of this product. This will allow time for developers to update and move past products that will no longer be available.

13. Engineering teams (including product, development, quality, release): All of these teams should have the same expectations for the future of this product. There should be a clear action plan on expectations when the requests come in about product enhancements, bugs, security issues, etc. All requests should be documented using the appropriate tracking software.

14. Security: In almost all software development companies that I have been in, there are some security scan tools that are used to ensure that vulnerabilities in software products are addressed. There should be a plan to run any tools necessary to find and fix any security issues.

15. Documentation: The team that is responsible for creating documentation on the website—and for creating release notes in the product and supporting documentation on integrations, customizations, features and functionality—should indicate the product is going to go away and ensure that appropriate actions are taken on all documents.

16. Dogfooding: Many companies test their own product and use it before it’s released to the external world. These internal groups need to be in sync with the decision to move away from the product. They will need to work on how to remove the product from testing, and re-setup hardware/software infrastructure.

17. Communication: Every company has an internet presence, and there are typically several channels on social media. Communication needs to be done on both internal and external channels that the company maintains. There should also be a work-back plan for expectations from the time a communication is sent out to the actual date of retirement for the product.

CITE: Sandhya Gupta  - ProjectManagement.com  7 Jan 2019


Comments