Productization: The Process Of Transforming From Customer .

Productization:The process of transforming fromcustomer-specific software developmentto product software developmentPeter ArtzInge van de WeerdSjaak BrinkkemperTechnical Report UU-CS-2010-003January 2010Department of Information and Computing SciencesUtrecht University, Utrecht, The Netherlandswww.cs.uu.nl

ISSN: 0924-3275Department of Information and Computing SciencesUtrecht UniversityP.O. Box 80.0893508 TB UtrechtThe Netherlands1

Table of contentsAbstract .51Introduction .61.1Problem statement .71.2Terminology .71.3Structure .82Research approach . 102.1Research questions . 102.2Research method . 102.2.1 Design-science . 102.2.2 Combined Design Science Model . 122.3Contribution . 142.4Validity . 143Related Literature . 163.1Software product . 163.2Software Product Management. 173.2.1 SPM process model vs. SPM reference framework. 173.2.2 Reference framework . 193.2.2.1Portfolio Management . 193.2.2.2Product Roadmapping . 203.2.2.3Release Planning . 203.2.2.4Requirements Management . 213.2.3 SPM Maturity Matrix . 213.3Productization . 223.3.1 Customer focus . 223.3.2 Requirements Engineering . 233.4Implications on SPM productization . 243.4.1 Portfolio management. 243.4.2 Product Roadmapping . 253.4.3 Release planning . 253.4.4 Requirement Management . 263.4.5 Summary . 264Productization process . 294.1Productization stages . 294.1.1 Introduction . 294.1.2 Stage 1: Independent Projects. 314.1.3 Stage 2: Project Feature Reuse . 324.1.4 Stage 3: Product Recognition . 334.1.5 Stage 4: Product Platform. 354.1.6 Stage 5: Standardizing Product Platform . 364.1.7 Stage 6 . 384.1.7.1Stage 6a: Customizable Software Product . 394.1.7.2Stage 6b: Standard Software Product . 404.2Validation . 414.2.1 Objective . 414.2.2 Expert panel . 414.2.2.1Clarification . 414.2.2.2End stages . 424.2.2.3Applicability. 434.2.2.4Merging stages . 432

4.2.2.5Integration of the reference framework. 444.2.3 Survey . 445Productization approach . 465.1Initial position . 475.1.1 Assessment . 475.1.2 Process Deliverable Diagram . 485.2Gap analysis . 485.2.1 Situational Factors . 485.2.2 Maturity Matrix . 495.2.3 Process Deliverable Diagram . 505.3Recommendations . 506Guidelines . 516.1General . 516.2Requirements Management . 536.3Release planning . 546.4Product Roadmapping . 566.5Portfolio Management . 576.6Overview of the guidelines . 596.7Validation . 596.7.1 Objective . 596.7.2 Expert panel . 607Business Case . 627.1Objective . 627.2Company description . 627.3Initial Position . 627.3.1 Software Product Management Assessment . 627.3.2 Process Deliverable Diagram . 637.4Gap analysis . 667.4.1 Situational Factors . 667.4.2 Maturity matrix. 687.4.3 Process Deliverable Diagram . 697.4.4 Conclusion. 707.5Recommendations . 717.5.1 General suggestions. 717.5.2 Portfolio Management . 727.5.3 Product Roadmapping . 727.5.4 Release planning . 747.5.5 Requirements Management . 777.5.6 Final remarks . 787.6Validation results . 798Conclusions, Discussion & Future Research . 818.1Conclusion . 818.2Discussion & future research . 83Abbreviations . 85References . 86Appendix A: Differences . 91Appendix B: Situational factors . 93Appendix C: Guidelines from literature. 95I. General . 95II. Requirements Management . 96III. Release Planning . 96IV. Product Roadmapping . 973

V. Portfolio Management. 98Appendix D: Assessment . 99I. General questions . 99II. Situational factors . 99III. Maturity questions . 100IV. SPM Productization. 100Appendix E: Process Delivery Diagram . 101I. Activity Descriptions. 101II. Concept Definitions . 1024

AbstractDeveloping a software product is getting increasing attention in the scientific field and societal field.Organizations are recognizing the potential benefits and importance of developing a product for amarket. Product software is defined as a packaged configuration which consists of softwarecomponents or a software-based service, with auxiliary materials, which is released for and traded ina specific market (Xu & Brinkkemper, 2005). Also organizations which develop software specificallyfor one customer have identified a need to change their software into a standard product. But howcan these organizations transform their software and create a standard software product? Yet, thereare few scientific studies reported on such transformation. This study stipulates the need for moreexploratory research on the transformation by identifying a productization process.This research presents several concepts and models, which are developed and validated withinthis research. The first result which we present in this study is an overview of twenty differencesbetween customized software development and standardized development. The second result is theproductization process, which we created as a result of the identified differences and a literaturestudy. The productization process describes the transformation from a customer-specific softwaredevelopment to a standard software product for an entire market. Also a complete graphical andtextual description of the entire process is provided, in which the characteristics of each stage aredescribed. The third result of this research is an approach to actually apply the productizationprocess within an organization. The productization approach is a method which consists of threesteps in order to define a custom advice how an organization should continue to become a softwareproduct business. Finally, the last result is a list with guideline for the implementation of the productmanagement functions from a reference framework for Software Product Management (Weerd etal., 2006a).Keywords: Productization, software product management, customer-specific software, customizablesoftware product, standard software product, transformation.5

1IntroductionA product manager is a relatively new function within a product software company; this is the resultof a transformation of focusing on customized software to developing software as a standard product(Weerd et al., 2006a). Within a small and midsized company a product manager is highly involved inmanaging the product strategy and the overall delivery process (Dver, 2003). Especially within smallproduct software companies Software Product Management (SPM) is essential. Usually thesecompanies base their whole business on one or two products (Kilpi, 1997). One of the first signs of afailure of product management is insufficient requirements engineering. The main reasons for thisfailure are the difficulties with misinterpreted needs, changing and creeping requirements, misseddeadlines and budgetary commitments and, more globally speaking, failing business opportunities(Ebert, 2007).The result of the study performed by Ebert (2007) showed that the strengthening of acoherent product management role improved the time to market, schedule adherence and handoverquality. Ebert also defined guidelines towards successful product management: Business objectives and accountability Mastering requirements Managing risks and uncertainty Leadership and teamworkIn order to be able to improve the product management processes, a specific approach is required.The best known maturity models are Capability Maturity Model (CMM) (Paulk et al., 1993), and itsfollow-up CMMI for implementing the capability maturity model (CMMI Product Team, 2002).However, a number of organizations find it too heavy and difficult to use CMMI (Nawrocki, 2002). Inaddition, Staples et al. (2007) found several other reasons why CMMI is not adopted: theorganization was too small, the services were too costly, and the organization had no time toimplement the process improvements. In addition, Brinkkemper et al. (2008) also elaborated on thefact that these methods are too superficial for the specific nature of product software companies.They introduced the Product Software Knowledge Infrastructure (PSKI), which helps product softwarecompanies by obtaining a custom-made advice for improving development processes (Weerd et al.,2006b). This infrastructure consists of an online systematic collection of methodical knowledge whichcan be used for improving the maturity of specific processes within an organization.A m

steps in order to define a custom advice how an organization should continue to become a software product business. Finally, the last result is a list with guideline for the implementation of the product management functions from a reference framework for Software Product Management (Weerd et al., 2006a).