A Xoriant Whitepaper

Transcription

1 A Xoriant Whitepaper

2 Tail Wagging the Dog Managing End-of-Life Phase of Software Products Many software product companies have found that releasing a new product is often easier than retiring an old one. While major organizational resources are spent in the product development and release cycles, many times product retirement becomes an expensive afterthought. Outdated software can turn into a monster for both software vendors as well as the users alike, if not planned properly. Both the parties (product vendor and customer) tend to look at the same issue from totally different angles, both completely legitimate, but which create a chance of major stomach pains if the end-of-life process management not planned and executed properly from both sides. Well-managed software companies have a well-documented process for managing end-of-life products. Many of them partner with external specialized services vendors to carry on the support and sustaining of their end-of-life products, while focusing their own resources on developing and supporting their newer versions. For the software vendor many simple but not-so-trivial problems arise: How do you discontinue a product that is no longer profitable? And how do you know that it s time? How do you plan product requirement with the same vigor that you use to plan birth and growth of a new product? It is very difficult to practice product life cycle management in real-life. What s the worst thing that can happen to the discontinued product? The worst thing is some possible complaints from those customers, who continue to use the old product. What about technical support? What about demands for a new feature? What about migration to new operating systems? How many development resources and other resources are being spent on the old product, which could be applied to a more strategically important product? While the software vendors do their best to move their existing enterprise clients to the newer and newer version of their software (and thereby have much less number of versions to be supported), many enterprise software users refuse to upgrade, thus continuing to use the old versions. Some of those reasons are: The old implementation works well. There is no reason to change anything. Cost of the upgrade heavily outweighs the extra benefits provided by the newer product versions

3 Larger than expected reimplementation project for little new functionality Expensive integration efforts break due to upgrades or system changes Lengthy (measured in months & years) implementation with continual delays Significant, unexpected costs of license transfer High-cost consultancy fees requiring specialized vendor delivered resources Even if software product vendors have identified the specific products to be retired, there are several execution challenges? Staffing: How do we practically staff up for technical support and sustaining engineering for a portfolio of retired products? If this portfolio comprises diverse products, it is likely that in the worst case scenario, these product companies end up having expensive resources managing the products, which are no longer strategically important to the company. It is also very difficult to retain these knowledgeable personnel, especially those who compare their jobs with the much more glamorous development jobs in the rest of the company. Processes and Knowledge: Since management of retired or retiring products is seldom considered to be a strategically important activity, software companies end up investing significantly fewer and insufficient resources in people, processes and systems (including knowledge management) in supporting this activity. Many times, employees who support these activities consider keeping this knowledge undocumented and in their own head as a means of job retention. Profitability/Longevity: Since the end-of-life announcement for the product has already been made, it is very difficult to estimate how long the maintenance revenue stream would continue for the product. It is reasonable to assume that many customers would be evaluating options such as upgrading from the same software vendor or replacing the product with a new solution. Hence, it is very difficult to assign resources profitably to support the product in the EOL status. What are the alternatives? To stretch the life and maintenance revenues and to maintain a lock on the customers for the postannouncement end-of-life products, many software product companies use the resources of strategic services partners to support these EOL products. Since the partner resources are trained to support the end-of-life products and since the processes, systems and knowledge management infrastructure of the partner are tuned for these support tasks, not only can these products be supported until it is

4 profitable to do so, but the partner resources can be scaled up and down to reflect the corresponding product maintenance revenues. This flexible staffing (and hence cost) model allows the product vendor to ensure that the end-of-life products are always profitable until the revenues naturally die. A typical product life cycle timeline using internal resources is shown below. It can be easily seen that since the internal resources are always tough to find, motivate and effectively deploy to support end-of-life products, the product typically stops yielding revenues after about one year after the announcement of end of life. Typical Product Life Cycle Timeline Internal Resources General Availability EOL Announcement Engineering Support 2-3 Years 3-6 Months Years On the other hand, a typical product life cycle timeline using partner resources can definitely be stretched almost by one to two and even more years, yielding more revenues, profits and higher customer satisfaction. Typical Product Life Cycle Timeline With Partner General Availability EOL Announcement Engineering Support 2-3 Years 3-6 Months 1-4 Years Partner Involvement Company Plus Partner Resources Partner Resources only

5 As mentioned earlier, using the resources of strategic product maintenance/support partners, the end-of-life products be supported until it is profitable to do so. Unlike the fixed cost model of internal support resources, the partner resource model becomes highly variable by scaling the partner resources up and down to reflect the corresponding product maintenance revenues, thus ensuring alltime profitability during the remaining life of the product. The following curve reflects the lifecycle revenues of a typical product with internal resources and partner resources. PRODUCT LIFE CYCLE REVENUES REVENUE MATURITY WITH PARTNER EXTRA REVENUES GROWTH DECLINE INTRODUCTION TIME EOL INTERNAL ANNOUNCEMENT It can be seen that the life span of a product after the end-of-life announcement typically increases for products which are supported by partner resources. This results in higher revenues for these partner supported products. Also, since the partner model is a variable cost model, it also yields higher life time profitability. Many companies are leveraging specialized partners to not only enhance the life cycle product revenues and profits, but also focus their internal resources on more strategic product development and support. The engineering and product managers of these product companies evaluate the product portfolio every year and identify the products for which the support can be transferred to the partner resources. That way, their own resources can be focused on more strategic products. It is the most effective way to focus on the core and outsourcing the context. Xoriant has been partnering with several product companies in the complete lifecycle of their software and systems products. That involves development, testing, support and implementation. In several

6 instances, Xoriant teams have sustained not only the old releases, but also the end-of-life products. Over two decades of supporting various technology customers, Xoriant has learnt that the most important factors for success of any product support and sustaining engagement can be summarized as: Process Define bug classification/tasks Periodic communications with customers and product vendor Define remediation process Infrastructure Define and achieve minimum required infrastructure for systems, communications, training and KM Leverage common infrastructure SUPPORT / SUSTAINING SUCCESS FACTORS People Select support oriented people Impact continous training Cross-training and skill backup Keep trained bench for hot swap Knowledge Management Use product vendor s KM system and process or partner s Disciplined assimilation, updates and dissemination of knowledge Over the years, Xoriant has performed several end-of-life support/sustaining of: Operating system, device drivers and languages for a systems manufacturer Several generations of products and tools for a middleware software vendor Customized versions of middleware products at two semiconductor and three financial services companies on behalf of the software vendor Old generations of wireless gateway and media deployment products of a wireless infrastructure software vendor License version of a enterprise class supply chain software product while the product company launched the SaaS version Xoriant teams understand that the most critical success factor in end-of-life support engagement is successful knowledge transition from the software product vendor teams to the specialized services vendor teams. Through multiple EOL engagements, Xoriant has developed a knowledge transition process that focuses on transition planning, knowledge assimilation, shadow support, assisted support

7 and knowledge dissimilation to wider group. This process mitigates the risks related to knowledge transition and increases the success probability of the engagement. Estimate Learn Observe Perform Change Study Transition Planning Plan Knowledge Transfer Shadow support Assisted Perform Support Steady state Optimize Baseline Demonstrate Demonstrate Verify Conclusion: With product releases coming to the market faster and faster, it becomes imperative for the software product vendors to have a well planned strategy for managing the retirement of their software products. Managing the end-of-life phase of the software products is very tricky since the runway available to the software product vendors when they should line up the resources to support the customers who would continue to use the product and pay for the support of the product is very difficult to predict. This means that the maintenance revenues and hence the revenues and the profits earned during the life of the product remaining after the end-of-life is announced are not easily predictable. Using a specialty vendor to perform the end-of-life support and sustaining activities makes it much easier for product companies to turn their fixed support commitments and costs into variable commitments and costs without sacrificing customer satisfaction. Besides, a specialty vendor who is in the business of support and sustaining has much easier time attracting and retaining the right people, who follow the right processes and have the right discipline to use and enhance the knowledge management systems. Having successfully performed support and sustaining activities for various products, current, old and end-of-life, for the last twenty years, Xoriant is well positioned to partner with software product companies for the end-of-life support of their retiring products. California New Jersey London Dubai Mumbai Pune Kolkata HQ : 1248 Reamwood Avenue Sunnyvale CA USA Tel: info@xoriant.com