Augustus 2012
M
A
S
T
E
R
’
S
T
H
E
S
I
S
MASTER’S THESIS
Status
Final
Version
V.01
Author: Kadri Guvendiren
Student number: 3376346
First supervisor: Sjaak Brinkkemper
Second supervisor: Slinger Jansen
Kadri Guvendiren – Student Number 3376346
PRODUCTIZATION PROCESS
Educational institution
Utrecht University
Year of study
2011/2012
Education
MBI
Company supervisors
Ronald ten Have
Edwin Bleijinga
Start date
03-10-2011
End date
31-7-2017
A
S
T
E
R
’
S
T
H
E
S
I
S
TRANSFORMING FROM DEVELOPING CUSTOMER
SPECIFIC SOFTWARE TO STANDARD PRODUCT
SOFTWARE
M
2
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Preface
This document contains my master thesis, which is the final product of ten months of research in
order to graduate for my master degree. After finishing my bachelor in Computer Sciences at the
Hogeschool Rotterdam, I decided to start the Master of Business Informatics (MBI) at the Utrecht
University in February 2010. This master thesis research has been carried out at Logica in cooperation with Utrecht University. During my research I received positive feedback on my
research, which explores the transformation process of service businesses to product businesses
in the Software industry. I hope that the results of this research will make a valuable contribution
to the knowledge on this topic.
3
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Content
PREFACE
3
CONTENT
4
ABSTRACT
7
1.
INTRODUCTION
8
2.
RESEARCH APPROACH
9
3.
4.
2.1.
Research questions
2.2.
Research method
9
10
2.2.1.
Literature study
10
2.2.2.
Semi-structured interviewing
11
2.2.3.
Validity
13
CONTRIBUTION
14
3.1.
Scientific contribution
14
3.2.
Societal relevance
15
THEORETICAL FRAMEWORK
4.1.
4.2.
4.3.
Productization
16
16
4.1.1.
Inbound productization
19
4.1.2.
Outbound productization
19
4.1.3.
Degree of productization
20
4.1.4.
Internationalization
21
Service or Product business
24
4.2.1.
Switch to product business
25
4.2.2.
Switch to service business
26
Characteristics of service business
27
4.3.1.
Business model of service business
28
4.3.2.
Organizational perspective
29
4.3.3.
Individual perspective
30
4.3.4.
Project-based service business
30
4
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4.3.5.
User involvement
35
4.3.6.
Software development
35
4.3.7.
Reusability in software development
37
4.3.8.
Service business benefits
38
4.3.9.
Overview of service business characteristics
39
4.4.
Product business characteristics
46
4.4.1.
Business model
47
4.4.2.
Software Product Management (SPM)
49
4.4.3.
Organization and development perspective
50
4.4.4.
Overview of product business characteristics
52
4.5.
Differences between service and product businesses
56
4.6.
Dimensions for productization process
61
4.7.
Software Product Management
63
4.7.1.
SPM maturity matrix
65
4.7.2.
Situational Assessment Method
66
5.
INTERVIEW RESULTS
68
6.
PRODUCTIZATION APPROACH
69
6.1.
Initial position
6.1.1.
6.2.
Gap analysis
10.
70
72
6.2.1.
Situational factors
72
6.2.2.
Maturity matrix
72
6.3.
9.
SPM maturity assessment
70
Recommendations
SPM MATURITY MEASUREMENTS
73
73
9.1.
Portfolio management
74
9.2.
Product planning
75
9.3.
Release management
76
9.4.
Requirements management
77
9.5.
Conclusion
78
MULTI-DIMENSIONAL PRODUCTIZATION PROFILE
10.1.
Productization profile of products
79
79
5
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
11.
SITUATIONAL FACTOR ANALYSIS
11.6.
13.
Conclusion
VALIDATION, DISCUSSION AND FURTHER RESEARCH
80
81
83
13.1.
Validation of productization process
83
13.2.
Validation of dimensions
84
13.3.
Discussion and further research
85
14.
CONCLUSION
87
15.
REFERENCES
90
16.
APPENDIX A – DIMENSIONS
100
17.
APPENDIX B – SELECTED APPLICABLE STAGES
136
18.
APPENDIX C – SPM MATURITY MEASUREMENTS
138
6
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Abstract
There are two types of businesses that we know in the Software industry: Service businesses that
develop customized software based on the customer specific needs and Product businesses that
develop standard software based on the market needs. Software product businesses can
sometimes switch to service business when their product sales start to decrease on the market
however it is indicated quite challenging to switch from service to product business. The
productization process enables the companies to transform themselves from service to product
business. This study aims to validate to what extent this process is applicable in a serviceoriented business.
The research presents different results captured based on an assessment of seven products on
the productization process in an IT service business. The first result concerns all the common
characteristics between service and product businesses from societal, marketing and sales,
company and development perspectives. These characteristics enabled us to identify the
additional dimensions for and to bring improvements in the productization process. The second
result concerns the application of productization approach, which consists of certain steps in
order to give specific recommendations for each of the analyzed products on how to become
market-oriented. Third result is related to the calculation of the average percentage on how
mature the products were in their product management practices and identifying thereby the
strong and weak areas per SPM focus area. Fourth result is the reflection and interpretation of
multi-dimensional productization profile of certain products based on their specific situation. The
fifth result is the analysis of all the situational factors of the products, where we identified some
concrete differences and similarities based on their current environments on their way to become
market-oriented. Finally, some specific recommendations have been provided on becoming
market-driven based on the assessment results of the seven analyzed products.
Keywords: Productization, Software product management, product software, service business,
transformation, custom software development, standard software development.
7
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
1. Introduction
Software product management is defined as the discipline and business process, which governs
a product from its inception to the market or customer delivery and service in order to generate
the biggest possible value to the business (Ebert, 2009). The product manager, who leads and
manages the product(s) from its inception to its delivery, executes this important task. Bekkers,
Weerd, Spruit & Brinkkemper (2010) developed a competence model for SPM, which includes the
relevant focus areas such as Portfolio management, Product planning, Release planning and
Requirements management. These focus areas help product managers to manage or improve
their SPM practices in the organization. Based on the focus areas in the SPM, Van de Weerd,
Bekkers, and Brinkkemper (2010) developed a maturity matrix, which guides further development
of methodical support in SPM. This means that the matrix can be used to assess an
organization’s current software product management capabilities and offer local, incremental
improvements to the product managers.
We distinguish two types of software: Customized and Standard software. Customized software
is software that is tailored to the needs of one specific customer with the purpose to satisfy that
customer and standard software is software that is designed based on the needs of a specific
market. Some software companies follow the customer-oriented approach in their strategy while
others choose to follow a market-oriented approach. Both approaches have their own advantages
and disadvantages (Sawyer, 2000).
Artz et.al (2010) found that several software companies that develop customer specific software
have identified a need to transform to developing and selling standard product software. In their
research, this transformation process is called ‘Productization process’, which consists of six
stages as follows:
Figure 1: Productization process (Artz, Weerd, Brinkkemper and Fieggen, 2010)
The process assists organizations in becoming a product software business. Artz et al. (2010)
evaluated the process with the methods such as expert reviews and a business case. However
the authors recognize the fact that more thorough validation is necessary to prove the
applicability of the productization process.
8
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
2. Research approach
In this research, potential products are analyzed for the productization process. By looking at the
initial position of the products on the productization process and the implemented processes from
a software product management perspective, a specific recommendation will be given to Logica
to develop a custom project and/or product as a standard product focused on a certain market.
This section presents the defined research questions, research methods, and the validity threats
of the research.
2.1. Research questions
A further validation/evaluation of the productization process leads to the following main research
question:
“To what extent is the productization process applicable in a service-oriented company when
transforming from developing customer-specific software to standard product software?”
To answer the main question, the following sub-questions are defined, which will be answered
within the upcoming sections of the research:
1. What are the dimensions in the productization process that are needed to be able to
position a company’s product at a certain stage?
2. Are there more, or fewer stages needed to implement in practice?
3. What are the challenges that companies face when transforming from developing custom
software to standard product software?
4. Which processes need to be implemented to go from one stage to another in the
productization process?
9
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
2.2. Research method
In conducting this research, we apply the methods such as the literature study and (semistructured) interviewing to capture the relevant data on productization process. As mentioned in
chapter 2.1, the main question of the research is split up in four research questions which all
cover a phase of a research. In Table 1 the research questions, the related research methods,
and their corresponding chapter, are shown.
Question
RQ1
What
are
the
dimensions
in
the
Method
Chapter
Literature study
Chapter 4 (sections:
4.3.9 – 4.4.4 and 4.5)
productization process that are needed
to be able to position a company’s
product at a certain stage?
RQ2
RQ3
Are there more, or fewer stages needed
(Semi-structured)
to implement in practice?
interviewing
What
are
the
challenges
that
companies face when transforming from
(Semi-structured)
13 + 14
11 + 12
interviewing
developing custom software to standard
product software?
RQ4
Which
processes
need
to
be
(Semi-structured)
implemented to go from one stage to
interviewing
another in the productization process?
(Business cases)
7+8 +9
Table 1: Research questions, methods and corresponding chapters
2.2.1. Literature study
The first step of the research is to perform an extensive literature study on productization
process. Hart (1998) defines the literature study as “ the use of ideas in the literature to justify the
particular approach to the topic, the selection of methods, and demonstration that this research
contributes something new (p.1). According to author, quality for the literature review means, “
appropriate breadth and depth, rigor and consistency, clarity and brevity, and effective analysis
and synthesis.” J. Shaw (1995) states that the process of the review should “explain how one
piece of research builds on another” (p. 326).
The aim behind this study is based firstly on the identification of other similar processes in the
literature that focus on productizing of custom software projects and secondly; Since
productization process involves the evolution of custom software to standard product software,
the literature study is also performed on identifying the characteristics of custom and standard
10
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
software. The output that is retrieved from the literature study will be used as input to identify or to
improve dimensions from Artz et.al (2010) for each productization stage on the process. This
output will also enable us to give answer to the first research (sub)-question on the relevant
dimensions for the transformation from custom software to standard software.
A systematic literature review (SLR) will be performed to build a database of relevant publications
for this research project. Kichenham (2004) defines SLR as a means of identifying, evaluating
and interpreting all available research relevant to a particular research question, or topic area, or
phenomenon of interest. The aim is to find as many previous studies on the topics as possible
using an unbiased search strategy. To get a broad overview of past research on the relevant
topics, the following databases will be consulted: IEEE XPlore, IEEE, ISI Web of science, Science
direct, Elsevier, Springerlink, Wiley, Mendeley, etc. A secondary search will also be performed
tracing the reference lists of the relevant research papers, which result in the original sources.
2.2.2. Semi-structured interviewing
Semi-structured interviewing is conducted as a second step of the research with the aim to
assess the potential products on the productization process. In semi-structured interviewing, “a
guide is used with questions and topics that must be covered. The interviewer has some
discretion about the order in which the questions are asked, but the questions are standardized,
and probes are provided to ensure that the researcher covers the correct material” (Harrel &
Bradley, 2009).
a) Interview candidates
Perry (1998) suggest that interview candidates can be identified using a purposeful
sampling approach, which ensures that the researcher can evaluate each candidate in
how far he/she is suitable for the interview by considering his/her requisite knowledge
and experience. The most significant aspect considered in identifying the interview
candidates is related to their experience in the software service industry. The focus is on
identifying the professionals with greater than five years of experience in the software
services industry. In addition, the roles that the professionals hold are also taken into
account to see whether they can provide an added value on the subject of the research.
11
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
b) Interview technique
Since this thesis project concerns a qualitative research, the data needs to be collected
from different stakeholders. In this sense, the key issue for collecting the data is the
question of recording the interviews with the aim to support capturing information. A
recorder is an indispensible aid during the interviews (Patton, 2002). The author
indicates that using a recording device may allow the interviewer to focus on the
interview instead of taking notes. During the interviews, the interviewees will be asked
whether a recorder may be used to capture essential data.
c) Interview structure and analysis
The interviews are performed in three parts: first part consists of maturity assessment of
the potential products based on the maturity matrix standard questions created by
Weerd et.al (2009) from the software product management perspective. Second part
consists of the assessment of productization process with its corresponding dimensions,
where we determine the initial position and desirable position of the products. Third part
is the validation of the captured results from the first and second interviews. The first part
is performed by means of a structured interview protocol, where the interviewer
introduces himself, explains the aim of the research and the goal of the interview. Finally
permission is asked to the interviewee whether the interview may be recorded. The
standard questions related to SPM maturity are asked to identify the maturity of product
management processes of each potential product. In the second part, the interviewees
are asked their opinions on the corresponding stages and related dimensions of
productization process and in addition they are asked to select the applicable stages for
each potential product to determine the initial position of each product on the process.
The interviewer asked hereby open-ended questions to capture as much relevant and
essential information as he/she could on the productization process. After the interviews,
the recorded data are transcribed, analyzed and documented. The results from the SPM
maturity and productization process assessment are combined together and validated
with the interviewees by explaining firstly the analysis part of the interviews, reflecting
the specific situation of each product based on the SPM maturity level and initial
position.
12
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
2.2.3. Validity
Yin (2003) states that three types of validity are important in the exploratory case studies. Firstly,
Construct validity concerns the validity of the research method. Multiple data triangulation
techniques may be applied in the sense that different stakeholders from different points of view
will be interviewed to verify a certain data retrieved. In the semi-structured interviews for maturity
and productization process assessment, we made sure that the relevant concepts are correctly
made operational and measured. For the determination of maturity level of each product, where
we asked standard questions, we applied for example the viewpoints of software developer,
project manager and sales manager in order to get a better representative result. In addition, we
performed also explorative interviews with the interviewees in advance with the aim to enlarge the
reliability and to smoothen the proceeding of the interviews. All the interviewees were well
informed in advance of the interview.
Secondly, Internal validity is the extent to which a study’s results can be interpreted accurately.
We tried to evaluate productization process whether it was applicable in a service-oriented
company. For an internal validity of the research, we identified cases that differ from each other
based on their situational factors with the aim to prove the applicability of the process. In addition,
the selected interviewees differed a lot based on their experience and domain expertise.
Thirdly, External validity refers to how the data can be applied beyond the circumstances of the
case to more general situations. For the maturity assessment of each product, we combined the
gathered results of the practical field with the gathered results of scientific field. We made for
example a comparison between the products based on their situational factors by considering the
reference values obtained from Bekkers et.al (2006) from the scientific perspective.
Finally reliability indicates that the results of the study can be replicated. Since this research
evaluates and validates the productization process, we performed the productization approach
that is presented by Artz et.al (2010) for the assessment product. Hereby all the procedures and
steps have also been recorded. The business cases consisted of interview notes, documentation
on maturity assessment and productization dimensions. We performed also maturity assessment
for each product by making use of fixed standard questions from Weerd et.al (2009). The
reliability is hereby guaranteed. When another interviewer performs the application of the model,
the same results will be produced.
13
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
3. Contribution
The objective of this research is based on the productization process, which assists organizations
to become product software business. The project aims to provide a thorough validation of all the
identified process steps during the productization by applying them in a service-oriented
company. This research has both the scientific and societal relevance.
3.1. Scientific contribution
In the literature there are several scientific research studies available focusing on product
software (Xu & Brinkkemper, 2007) such as product development (MacCormack, 2001), (Hietala,
Kontio, Jokinen, & Pyysiainen, 2004), management of software products (van de Weerd,
Brinkkemper, Nieuwenhuis, Versendaal, & Bijlsma, 2006), (Ebert, 2009), (Bekkers, Weerd, Spruit
& Brinkkemper, 2010), requirements management (Regnell, Höst, Natoch Dag, Beremark, &
Hjelm, 2001), (Carlshamre, Sandahl, Lindvall, Regnell, & Natt och Dag, 2001 ), release planning
(van den Akker, Brinkkemper, van Diepen, & Versendaal, 2005), (Ruhe & Saliu, 2005), product
line engineering (Pohl, Böckle, & van der Linden, 2005), (Kang, Jaejoon, & Donohoe, 2002),
product delivery (Jansen, Ballintijn, Brinkkemper, & van Nieuwland, 2006) and so on. Despite the
fact that there is an extensive research on the development of software as a product, some
information concerning the development of product software is lacking (Weerd, 2009). Xu and
Brinkkemper (2007) state that by generalizing the experiences from product development, a body
of knowledge needs to be established with theories, methods and tools. In this sense, from the
product development perspective, this research takes the statement of Xu and Brinkkemper as a
basis and aims to make a contribution to the literature by increasing the knowledge on the
transformation process of software companies from developing customer-specific software to
standard product software since this process is not widely studied. In addition, this research is a
validation of productization process (Artz et al., 2010) and it also improves and validates the
defined set of criteria by (Artz et.al, 2010) for each stage in the productization process, which can
be then used for the assessment of an organization’s initial position based on the development of
software as a product. Finally this research project creates many opportunities for further
research on the transformation process from customer-specific development to standard product
software development.
14
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
3.2. Societal relevance
The product software industry is “among the most rapidly growing sectors in OECD countries with
strong increases in added value, employment and R&D investments” (OECD, 2002). This
industry builds software as a standardized product, which is sold to many customers (Xu &
Brinkkemper, 2005). Heitlager, Jansen, Helms and Brinkkemper (2006) state that the construction
of a new piece of software in a (start-up) company can be challenging because the market is
unknown and therefore the revenues and requirements are uncertain, hard to predict. Further, the
team is new and the platform to develop against is still to be selected. These challenges
mentioned are also the same for those companies, which want to transform themselves from
developing customer-specific software to standard product software. The product software
industry is much in need of having a unified theory on the evolution of software and software
process (Lehman, 2001), (Lehman & Rahmil, 2001) “as some feel that they have to ‘rewrite the
books’ of software engineering” (Heitlager et al., 2006), (Macmanus, 2009), (O'Reilly, 2005).
Aim of this research is to provide a contribution to the product software industry. A set of
guidelines will be provided to software companies, which want to become market-driven.
Specifically, during the transformation from customer-specific development to market-specific
development, the companies will be able to assess themselves in which productization stage they
are positioned and which processes they will need to implement further for software to be
developed as a product. Further the validated productization process can aid product managers
to improve or manage their SPM practices in an organization.
15
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4. Theoretical framework
4.1. Productization
Productization means standardization of the elements in the offering. It includes several
technological elements from the very early stages of designing a product (i.e. managing the
requirements, selection of technological platforms, design of product architecture etc.) to the
commercial elements of selling and distributing the product (i.e. delivery channels, positioning of
the product/company and after-sales activities) (Hietala, Jokinen, Bauer, Maula, Leino, Kontio
and Autio, 2004). Some of the key elements influencing the degree of productization are product
market, concepts, benefits, positioning, requirements, features, specifications, delivery channel,
marketing, selling and packaging (Cooper, 2000). According to Simula, Lehtimaki and Salo
(2008), the term productization is mainly used in the context of service or software industries with
the purpose to transform intangible services into more product-like, defined set of deliverables.
Based on internationalization of software firms, Alajoutsijarvi, Mannermaa and Tikkanen (1999)
describe productization as “a shift from unique service-intensive customer projects towards
tangible standardized products aimed at international mass markets”.
Two concepts are described that share some similarities of productization: commercialization and
mass customization. Pine (1993) describes mass customization as a “one type of production
system where all the employees share the goal of developing, producing, marketing, and
delivering competitive offering (i.e. combination of goods and services) with some variety and
customization so that valuable offering is developed”. The goal that is achieved with mass
customization is that a firm manufactures products with lowest possible costs and in high volume.
In this sense, the economies of scale and minor modifications are of great importance to generic
product.
“Commercialization is the cross-disciplinary process of taking a new product from
development to market, which includes such activities as production launch and ramp-up,
marketing materials and program development, supply chain development, sales channel
development, training development, training and service and support development”
(PDMA,
2004). Simula et.al (2008) state, that “commercialization is a broader and more marketing related
concept, whereas productization concerns both marketing and engineering. The purpose of
productization is to clarify and rationalize the offering for the firm (more efficient operations) and
for the customer (more appealing offering). The purpose behind commercialization is to introduce
a new technology or a product to the market.”
Based on the repeatable solutions/projects that are implemented at different customers, a firm or
organization can produce an unambiguously defined offering. The process to make the defined
offering a product is called “Productization” (Simula et.al, 2008).
16
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
By adopting the Software Product Management functions defined by Weerd et.al (2009), Artz,
van de Weerd, Brinkkemper, & Fieggen (2010) developed the productization process, which
enables companies to transform from developing customer specific custom solution to product
software. The emphasis of this transformation lies in the fact that while transforming to product
software business, customer satisfaction continues to be the main focus at these companies.
Since this thesis project is the validation of the productization process by Artz et.al (2010) at a
service company, the literature study investigates any research relevant to productization with the
aim to contribute more insight knowledge on the subject and to develop or improve the process
further on.
Artz et.al (2010) identified six stages for the productization process, which describe the situations
from customer specific development perspective to product software business perspective. The
stages are described as follows:

Stage 1 (Independent projects): This stage describes the situation of a service
organization, which provides specific solutions per customer on project basis. According
to Artz et.al (2010), these projects are executed independently from each other and differ
in budget, technology and functionality. They share barely any standard functions or
features.

Stage 2 (Reuse across projects): at this stage, reusability of existing components,
functionalities and features is the main focus across projects. Artz et.al (2010) state that
reusing existing components from finished projects provides companies the advantage to
increase the overall quality and reliability of software since they already have been tested
within previous projects. At this stage, custom implemented features are still larger than
standard features.

Stage 3 (Product recognition): this stage describes the situation, where a company
identifies the similarities of customers’ wishes, which lead to the identification of a product
scope. At this stage, the standardized part of the projects is larger than the customized
parts because of the reused functionalities, components and features. This stage
concerns also the decision moment to develop the identified product further on and to
become market-driven business.

Stage 4 (Product basis): This stage represents the situation, where the basis is created
for the identified product. This means that a company needs to develop a long-term plan
to bring the product on the market. This stage is described by Artz et.al (2010) as follows:
17
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
“A set of features that form a common structure, from which a stream of derivative
products can be efficiently customized, developed and produced”. A company starts at
this stage to gather market requirements to determine the content of future releases of
the product.

Stage 5 (Standardized Product platform): at this stage, the company changes toward
market orientation and brings the emerging product to the market. Comparing to stage 4,
the set of features, components and functionalities are increased through the product
platform. The definition of this stage by Artz et.al (2010) as follows: “increasing the set of
features that form a common structure and introduce releases, from which still a stream
of derivative products can be efficiently customized, developed and produced”.

Stage 6a (Customizable product): this stage describes the situation, where companies
offer their product software as customizable product for specific customers.

Stage 6b (Standard product): this stage describes the situation, where companies offer
their product software as fully standard.
Conceptual illustration of productization is shown as follows in Figure 2:
Figure 2: Productization framework (Simula et.al, 2008)
As it can be seen on the framework, productization is introduced as a common nominator that
covers both New Product Development (NPD) and marketing related aspects from a product
centric viewpoint. New Product development is the process, which involves all the internal
activities to develop products or services before they are delivered to a certain market (Takeuchi
18
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
& Nonaka, 1986). Simula et.al (2008) states that NPD process matters the inbound productization
on the framework and the marketing related aspects matter the outbound productization.
4.1.1. Inbound productization
Inbound productization harmonizes and systemizes the offering delivery process and its outcome
inside an organization (Flamholtz, 1995). In inbound productization, a firm needs to have a core
product; this can be a very basic artifact or software program or anything that can be considered
to form the basis for what a firm sells. In order to have a core product, a firm has to create a path
from technology to a core product. In this sense, inbound productization means various
engineering related tasks such as: Final design specifications, material selection and sourcing,
production tools, assembly instructions, manufacturing ramp-up, product data management,
testing process and quality control, etc. From the software development perspective, this means
the tasks such as software programming, installation and configuration, data migration,
application integration, application testing, which are then performed in different development
models such as waterfall or SCRUM. Simula et.al (2008) call inbound productization as an ability
to make.
4.1.2. Outbound productization
The outbound productization is the other side of productization process. It works towards
increasing the value of a product perceived by customers. The things that add values on top of
the core product are; brand, design, training, after sales services etc. These are the outcomes of
external productization efforts, which a customer considers and values during his/her purchasing
decision. Flamholtz (1995) states that the success of the overall productization task is dependent
on the firm’s understanding of market needs. It is also of great importance that a firm understands
the end customer requirements early in the process of inbound productization and develops and
concretizes the offering in a manner that satisfies the customer.
In the sense of outbound
productization, a firm needs already to determine which market segments to enter and what ideas
to implement and how to prioritize them (Beane and Ennis, 1987). Quite often engineering or
product creation functions do not pay too much attention to the other activities that are needed in
order a firm to have a complete, consistent and sellable product, which is called ‘an extended
product’. An extended product is the outcome of outbound productization efforts and these in
practice mean various marketing related tasks such as: Branding and naming, warranties and
technical support, user guides and documentation, advertisements, brochures and white papers,
customer testimonials, contracts and/or license terms, sales channels and commissions, sales
tools and pricelists, logistic and packaging. Simula et.al (2008) call outbound productization as an
ability to sell. The overall conclusion that the authors take is that a firm has to be able to create a
balance between ability to make and ability to sell in order to be successful in its overall
productization efforts.
19
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4.1.3. Degree of productization
As stated earlier, the goal of productization is to package the offering, technology or service, so
that a customer can understand the content of it in advance. Productization consists of defining,
describing, improving, producing and continuously developing the offering so that customer
benefits are maximized and the organization’s goals are achieved.
Figure 3 shows the productization level in the context of technology. Service oriented and
technology based companies go through three stages when productizing their offerings. The first
stage concerns “Technology & willing to serve”, where the companies deliver solutions/services
to their customers based on the specific needs. In the first stage, the productization level is still
low and the abstraction level of defining a product offering is still vague. The companies reach
stage two “Core product & Service description” when they can identify and develop a core
product based on the repeatable solutions for example. In this sense, productization level goes
also higher because of a defined (product) offering and the abstraction level becomes hereby
more concrete. On the highest productization level, there is stage three, which concerns the
extended product or productized service, where the companies are able to bring a product on the
market that meets the expectations of an end customer. It can thus be seen on Figure 4 that the
productization level increases as the maturity of offering raises. This also removes abstraction
level and the outcome of productization, being it a service or product, making it easier to
communicate to an end customer.
Figure 3: Productization level in context of technology and service (Simula et.al, 2008)
According to Hoch et.al. (1999), the degree of productization is crucial for differentiating between
software product and project business. The degree of productization ranges from standard
packaged software products that are delivered ‘as-is’, i.e. without any changes to a large number
of customers, to customer tailored software, i.e. software that is developed according to the
20
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
needs and specifications of individual customers. The spectrum and the positioning of software
products within are shown as follows:
Figure 4: Software product and service business (Hoch et al. 1999)
Based on Figure 4, there are two types of businesses to identify: Service business and Product
business. Service businesses deliver custom software solutions based on the specific needs of
their customers and “all of their revenue comes from services and custom-built systems. The
companies that fit into this business type are for example PricewaterhouseCoopers, EDS,
Accenture, Cap Gemini and Ernst & Young” (Cusumano, 2004).
Product business delivers
software products, which are developed based on the needs of a certain market instead of
specific customers (Artz, et.al, 2010). The companies that fit into this type of business are
Microsoft and Adobe (Cusumano, 2004). There are also some vendors that operate as product
business but they are also close to services business model. Their revenue comes from both
services and maintenance contracts. These vendors deliver Enterprise solutions, which are the
software solutions/products that need customization (Artz et.al, 2010). The companies that fit into
this type of product business are SAP, PeopleSoft or I2 Technologies.
4.1.4. Internationalization
Internationalization and productization are the key importance areas for a continued growth in the
context of the software industry (Alajoutsijarvi et.al, 1999). Internationalization is described as
gradual development, in terms of involvement and entry forms, in which firms are expected to
target gradually more distant markets” (Moen, Gavlen, & Endresen, 2004). “Internationalization is
the process by which the firms both increase their awareness of the direct and indirect influences
of international transactions on their future and establish and conduct transactions with other
countries” (Beamish, 1990). Alajoutsijarvi et.al (1999) state that small software firms do business
in the tailored software segment in their own home country with the focus on long-term customer
relationships however these firms intend to enter the international packaged software market,
21
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
which operates very different from the familiar local context. Bell, McNaughton, Young, & Crick
(2003) illustrates internationalization as follows:
Figure 5: Internationalization of small firm (Bell et.al, 2003)
According to Figure 5, internationalization is based on the internal and external environmental
factors that can challenge software firms when deciding to internationalize. The external
environmental factors involve foreign market conditions (e.g. trade barriers, standards),
industry/sector trends and vicious/virtuous economic cycle. Internal factors involve firm’s human
resources (for example: experience of management in internationalization and business),
financial resources (e.g. willingness or ability to take risk or being able to attract foreign funding),
management competences (e.g. planning skills, technological skills or innovativeness) and
knowledge base (e.g. tacit knowledge across the organization and how efficient the knowledge is
transferable).
There are two pathways to see on the figure: organic pathway and born global pathway. Firms
on Born global pathway undergo rapid growth through internationalization. This comes more or
less from being the first mover on a certain market segment for example. Born global firms invest
in research and development, which means that sales process takes place after development.
Since these types of firms are competitive-oriented and their products may become obsolete
rather quickly, they aim to penetrate all major markets. These types of firms are similar to the
product software business based on the mentioned characteristics. The firms on organic pathway
are typical service businesses that operate in home market. Internationalization is achieved
22
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
through the internal process ‘learning by doing’. As it can be seen on the Figure,
internationalization is performed as follows: the firms invest firstly in one of the countries that are
not far away from the home market geographically (neighboring countries), rather than in several
countries at the same time, when they carry out investments in a specific country very carefully
and concurrently, the firm’s representatives, who operate in that specific market are learning as
they go (Bell et.al, 2003).
One of the challenges during the growth and internationalization of small firms concerns for
example the managerial competence in marketing since many software firms focus more
traditionally on the development of technology (Alajoutsijarvi et.al, 1999). Internationalization from
the marketing point of view for the software firms concerns two types of marketing approaches:
Marketing-mix approach and Relational marketing. Marketing mix approach focuses on the shortterm exchange of basic products in a highly competitive market. This approach consists of
product, price, place and promotion (4P’s) decisions for the competition in the target market.
Relational marketing concerns the collaborative relationship, in which the customer and the
supplier organizations form strong social, economic, technical and legal bonds over time in order
to achieve mutual benefit. This approach is applied mostly when software firms deliver tailored
systems to its customers with the aim to build long-term customer relationships and to win the
trust of their customers. According to Alajoutsijarvi et.al (1999), internationalization can only be
achieved by adopting some features from both marketing approaches. Based on the adoption of
the two marketing approaches, software firms that want to enter the foreign markets need to
identify actions, which decrease the uncertainty and risks perceived by foreign customers. One
important action that contributes to this is productization. Alajoutsijarvi et.al (1999) claim that
productization reduces for example the risk related to the software product, since the buyers can
test the functionalities of that relevant software product before the purchase decision is made.
This is not possible when buying custom specific software. Another important action concerns
establishment of credibility as reliable suppliers when entering foreign markets. In this sense,
trust, customer loyalty and mutual benefit between the partners in the target market play also a
crucial role.
23
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4.2. Service or Product business
We can characterize the productization process by a line with two ends; one end is called
‘Customer-specific software development’ and the other end is called ‘standard product software
development’. Customer specific software development is applied in service-oriented companies
while standard product software development is applied in product companies. Since both
companies follow different business models from a strategic point of view, we will firstly shed light
on how the service and product companies are operating in general terms and later in the
upcoming sections, all the characteristics of service-orientation versus product-orientation will be
identified.
a) Service business
Service is the application of specialized competences (skills and knowledge) through
deeds, processes and performances for the benefit of another entity or the entity itself
(self-service) (Vargo and Lusch, 2000). Hogan, Hogan and Busch (1984) define service
business as “the disposition to be helpful, thoughtful, considerate and cooperative at the
individual
level”
whereas
at
organizational
level,
service
business
describes
organizational policies, practices and procedures that support service excellence (Lynn,
Lytle and Bobek, 2000). From the software industry, Cusumano (2004) defines service
businesses as “businesses focusing heavily on customizing the products for each
customer and providing services such as strategy advice, training, and integration work
with other software systems, as well as selling large amount of maintenance (special
product enhancements as well as regular product upgrades sold under long-term
contracts) and technical support”. The best-known examples of this type of business are
consulting companies such as Accenture, Cap Gemini, Logica, and Ernst & Young etc.
b) Product business
Product companies are companies that “generate revenue through sales of “shrinkwrapped” software packages. In this sense, product companies make and sell a lot of
copies of whatever products they make as is – that is, without adding changes such as
one-of-a-kind features for individual customers” (Cusumano, 2004) or the products that
need customization (called “Enterprise solutions) (Artz, et.al, 2010). The best- known
examples of this type of business are the companies such as Microsoft, Adobe, Intuit,
and Business Objects.
24
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
c) Hybrid business
There are also companies that focus on the delivery of software through some
combination of product- and service business as a strategic choice, which is called
“Hybrid-orientation”. According to Cusumano (2004), “the primary focus of hybrid
solutions companies is to sell a mixture of products and services, with maintenance
upgrades or special product enhancements that must be supported in the future. Often
these companies have not been able to or do not want to productize their technology
fully”. Hybrid-orientation exists when companies are for example in a state of
transformation between product and service orientations. The best- known examples of
this type of business are PeopleSoft, SAP, IBM, Cisco, Hewlett Packard, etc.
Figure 6: Three Business and lifecycle models of software companies (Cusumano, 2004)
4.2.1. Switch to product business
Robert (1990) states that based on a research study of 114 technology-based firms within the
Greater Boston Area, “companies evolve over the first several years after founding toward more
product-oriented businesses and away from consulting and R&D contracting, and increased
orientation of the founders to sales and marketing, with lessened emphasis on engineering”. He
also concludes that, the more a software company matures over the years, the more likely that
the transition from product orientation to service orientation decreases. The reasons that
companies prefer product orientation to service orientation have to do with the financial benefits
(e.g. increased sales revenue and lower production costs) they gain with a strong product on the
market compared to services (Robert, 1990; Alajoutsijarvi et.al, 1999, Cusumano, 2004). As
Cusumano (2004) states in his book “If it costs you roughly the same to make one copy or one
million copies of a product, you would be a fool not to want to make and sell a million copies of
every product you create.”
25
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Based on the initial type of business, Robert (1990) states that in many cases, “the founders hope
to do some consulting or contract research and development, while living on the income from this
work, plan to develop a product or find a product that they can exploit”. The author concludes that
it is not surprising to find a great number of companies engaging in consulting and R&D work at
the initial state of their business. Transforming from providing customer specific software services
to developing standard products for a mass market is a difficult process (Cusumano, 2004;
Lassila, 2006). Hoch et.al (1999) state for example that professional services companies follow a
failure pattern in the sense that after having developed a number of more or less similar systems
for several clients, they try to develop a standard product with the same functionality for dozens, if
not hundreds or thousands of users. At the end, they are often wrong. According to Hoch et.al
(1999), the reason for this failure is that “mass-market products must be designed more broadly
than custom-made code in the service business, as they must address many more possible
applications and challenges”.
In the book of Business Software, Cusumano (2004) gives examples of companies that failed to
transform from service orientation to product orientation. One of the examples is i2 Technologies,
which “had a meteoric rise in the market for factory planning and supply chain management
software. It went from $2 million in sales in 1992 to almost $900 million in 2001, but also lost
nearly $8 million that year, although most of these losses were write-offs of devaluated
acquisitions. I2 Technologies remains an example of a company that grew too fast during the
height of the Internet bubble. The company nearly lost its focus and ability to serve customers.
During transformation from service orientation to product orientation, keeping the customer
satisfied is also an important challenge (Vandermerwe, 1995). In the case of IBM for example,
IBM failed to recognize environmental changes and customer preferences. In this sense, IBM had
lost sight of its customers and marketplace.
4.2.2. Switch to service business
More recent literature indicates that product companies in the software industry transform
themselves from product to more service orientation. According to Cusumano (2008), this has to
do with a decline in the product sales, license fees, new business and pricing models such as
Software as a Service (SAAS) and free but not free software. In this sense, the revenues of
product oriented firms shift to services. Another reason for the shift from product to service
business is the commoditization of the products on the market and dropping price points
(Cusumano, 2004). Lassila (2006) shows that a software product company can expand its
business with services. Author offers SAAS model, which enables customers to focus on their
core competencies, provides easier access to technical expertise and offers economical access
to valuable software applications at any time and from anywhere. Cusumano (2004) suggests
26
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
that companies in the service business may also want to try to productize or package their
offerings to increase profit margins and growth potential.
4.3. Characteristics of service business
This section identifies the characteristics of service and it is worth to state the observations of
Gerstner (2002) on service business based on his experiences at IBM. He states that the
“economics of service-oriented business are different because a services contract might last six
to ten years (an outsourcing contract). These contracts may lose money for the first year but may
still be profitable as a whole. This concept does not exist in the product-oriented business. The
skills required to manage service processes differ very much from the processes that drive
successful product companies”. According to Gerstner (2002), IBM had struggle through the
transition because the company had no experience in building a labor-based business. He also
mentions about the difficulties that are faced during the transition in his observations: “We were
expert at managing factories and developing technologies. We understood costs of goods and
inventory turns and manufacturing. But human intensive services business is entirely different. In
services, you don’t make a product and then sell it. You sell a capability. You sell knowledge. You
create it the same time you deliver it.”
“Service-oriented companies are knowledge intensive and have the characteristics such as; their
‘products’ are intangible, i.e. they do not consist of goods but of complex problem-solving
services; their ‘production process’ is non-standardized and highly dependent on teamwork; the
majority of their employees are educated and creative people; their customers are treated
individually and the ‘products’ are adapted to them than vice versa” (Apostolou & Mentzas, 1999).
For service oriented companies, “economies of scope are the “holy grail” to strive for, and these
come from structuring knowledge such as how to do requirements, manage projects, customize
applications, conduct user acceptance testing, or reuse design frameworks and even pieces of
code across different projects and customers” (Cusumano, 2004). In this sense, the focus of
these companies lies on satisfying their customers to meet the specific needs based on the
services. These services are delivered to the customers based on the agreed hours between the
relevant parties.
Based on their capabilities, software service companies create relationships with their individual
customers. According to Cusumano (2004), “service companies build technologies that look like
products or can be packaged in some way, but generally they cater to the needs of individual
clients”. Building capabilities in client management as well as project management are the main
focus areas. Service companies need to learn how to leverage technology and knowledge gained
in one project to other projects without compromising customer confidentiality.
27
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
It is a challenging task for a service business to enter the global market. Services business faces
the challenge to deliver software professionals (e.g. developers or project managers, testers etc.)
to the markets they want to enter. In this sense, delivering knowledgeable workers on the
international markets increases for example the costs of the delivery. The costs are related to
traveling, accommodation and expenses of those knowledgeable workers placed on international
projects (Koenig, 2005).
From a work culture perspective, Sawyer (2000) states that service companies are individualistic
oriented, which means that when the projects are finished or cancelled due to some reasons,
employees can leave the company to find work elsewhere.
Custom software development teams are characterized by team membership turnover, division of
labor by both phase and function, and disbanding following the completion of the first release
(Cusumano and Smith, 1997). Goodman, Ravlin and Argote (1989) describe them as ad-hoc
groups, not teams.
4.3.1. Business model of service business
Columbe (2000) states that service-oriented companies generate most of their revenue through
the sale of their services such as custom-software development, maintenance, support or
implementation of packaged software solutions like SAP, Oracle or Siebel, where the marginal
costs are relatively high. According to (Hoch et.al, 1999), there are almost constant and
significant marginal costs. Hoch et.al (1999) refer to a 1996 McKinsey’s analysis of 22 companies
showing that the cost of revenue is more than four times higher at services companies than at
product companies. Service companies are described as companies that are focused on the
people selling business instead of products one. Frye (1998) notes, that “people at the services
companies are expensive, repeatedly in every project. Even if Accenture consulting firm builds a
custom-made software solution for a customer today and a similar solution for another customer
tomorrow, the cost of both of them is not radically different”.
From a marketing and sales perspective, Hoch et.al (1999) state that the primary goal of serviceoriented companies is to win the trust of their customers. The reputation of a service-oriented
company is always critical to the customers since the quality of work at these types of companies
is difficult to measure earlier. Once there is a trust relationship between the customer and
service-oriented company, the goal is then to deepen the customer loyalty. Hoch et.al (1999) also
state that service companies reserve no budget for marketing activities as product companies do.
28
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4.3.2. Organizational perspective
Lytle, Hom and Mokwa (1998) review that the following ten fundamental elements effectively
represent the domain of organizational service orientation.
Figure 7: Service orientation elements (Lythe et.al, 1998)
Based on the model, Lythe et.al (1998) describe the elements as follows:
Service leadership practices: this element is critical for creating and maintaining an effective
and positive service orientation. Two foundational leadership elements are Servant Leaders, who
are actively engaged in helping, assisting, and meeting the needs of employees within the work
setting and Service Vision, which underscores the importance of service quality and customer
satisfaction in creating superior value for the organization.
Service encounter practices: Service encounters are employee interactions with customers.
They are important within the service orientation paradigm because brief encounters with
customers form the basis of important customer service quality evaluations (Parasuraman,
Zeithaml, and Berry, 1988; Zeithaml, Valerie, Berry and Parasuraman, 1996). Two important
dimensions are Customer Treatment, which aims to create positive customer perceptions of
service performance thereby enhancing the customer satisfaction, loyalty and organizational
profitability and Employee Empowerment, which aims to meet the customer needs as quickly and
effectively as possible.
Service systems practices: within this element, various important service-driven practices and
procedures must blend together in a service system to bring about the delivery of service quality
for the customer. When firms continue to make re-occurring and regular mistakes in delivery and
when they don’t keep promises, customers might lose the confidence in the firm’s ability to do
what is promised dependably and accurately.
29
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Human Resource Management practices: within this element, it is of great importance that an
organization invests in its employees. Hiring, training, and rewarding service oriented behaviours
have a direct and positive influence on service quality and organizational performance.
4.3.3. Individual perspective
Based on the individual perspective, Hogen et.al (1984) claim that the concept of service
orientation can be assessed by using measures of personality. The authors developed Service
Orientation Index (SOI) from Hogan Personality Inventory (HPI). Thanks to the SOI scale, it was
possible to measure the employees’ service orientation based on their personalities. There is a
distinction made between the employees, who are more service oriented and those, who are not.
The research results show that the employees are more service oriented when they have the
personality characteristics such as well adjusted, likable, socially competent and willing to follow
the rules and the employees, who have the personality characteristics such as rude, tactless and
socially inept are proven not to be service-oriented.
4.3.4. Project-based service business
Artto, Wikström, Hellström and Kujala (2008) analyze the role of services in the business model
of a project-based firm. Project-based firm is described as “a firm that provide solutions that
integrate a wide wealth of product, services and systems into their offerings to customers”.
According to the authors, “services have different roles and functions in the business of delivering
solutions or systems through projects”.
Based on their research results, the following six impact types are identified, each of which
illustrates a different way in which services can affect the business of a project-based firm:
30
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Impact type
Description of the impact
Customer entry
Refers to the desired effect of the service representing an entry point to a
specific customer or other customers in the market segment, for
additional services or projects in the future
Customer value
Refers to the effect of creating additional value to the customer with the
service, which obviously has a favorable impact on the supplier firm’s
margins and profitability in the delivery of single solution or in the overall
business
Competitive
Refers to the increase in the competitiveness of the company’s offerings
advantage
with a specific customer or in the market segment by making the
company’s offering more attractive than competitor’s offerings, or by
making the company’s offerings more difficult to imitate; this leads to
sustainable competitive advantage
Delivery efficiency
Refers to the service’s impact on delivery activities making them more
lean and cost-effective
Service business
Refers to the fact that the delivered service itself is justified as part of a
profitable business by creating for itself a steady and predictable revenue
stream
Innovation and
Refers to the service deliveries’ impact on creating new knowledge, or
learning
creating of new solutions and capabilities, which improves either the
specific project or service delivery at hand, or future deliveries and the
overall business of the project-based firm.
Table 3: Impact types of services in a project-based firm (Artto, et.al, 2008)
Artto et.al (2008) state that a complex system solution is usually delivered to the customer as a
project, which includes core product and related services to provide the required functionality for
the solution. Services related to a project occur before the project delivery, during the actual
project delivery (e.g. as integrated into project delivery), and after the project delivery. There are
different service types implemented in various phases of a project lifetime. These service types
are such as; consulting, consultative selling, conceptual design and feasibility studies,
configuration tools and methods for creating specifications, engineering design, systems
integration,
project/product
configuration,
delivery
process
planning,
training,
project
management, supply chain management, procurement, commissioning and handing over, BuildOperate-Transfer (BOT), maintenance, operations support/service centers, centralized operations
service centers, open web-based and real-time information sharing, outsourcing, asset sharing
and financing.
31
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Artto et.al (2008) discuss their findings based on the identified impact types and across the whole
lifetime (before, during and after) of a project. The observed service types mapped to impact
types are shown in Table 4 as follows:
Time frame
Impact type
Observed service types
Before the project
Customer entry
Consulting, consultative selling,
conceptual design and feasibility
studies, joint development and
innovation activities, configuration
tools and methods for creating
specifications
Customer value
Engineering design and system
integration
Competitive advantage
Consulting, conceptual design,
systems integration
Delivery efficiency
Project/product configurator,
training
Service Business
Maintenance, operations support
Innovation and learning
Consulting, conceptual design and
system integration
During the project
Customer entry
Delivery process planning
Customer value
Training, project management,
systems integration, engineering
and design
Competitive advantage
Core project and inherent service
offering
Delivery efficiency
Supply chain management,
procurement, commissioning and
handing over
Service business
Core project and inherent service
offering, Build-Operate-Transfer
(BOT)
Innovation and learning
Engineering and design, systems
integration, project management,
delivery process planning
After the project
Customer entry
Consulting, optimization,
maintenance and training
32
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Customer value
Systems integration, optimization,
upgrades, modernizations,
extensions, maintenance,
operations support, outsourcing,
asset sharing, financing, localized
operations support/service centers,
open web-based and real time
information sharing
Competitive advantage
Outsourcing and asset sharing
Delivery efficiency
Centralized operations service
centers, maintenance and
operations support
Service business
Consulting, systems optimization,
systems integration, training,
maintenance, operations support,
outsourcing and asset sharing
Innovation and learning
Maintenance, operations support,
diagnostics for customers’ systems,
consulting and optimization
Table 4: Service types of a project’s lifetime (Artto et.al, 2008)
Artto et.al (2008) conclude, that consulting types of services such as consulting, technical
services, conceptual design and feasibility studies, optimization, and systems integration play an
important role in all the identified impact types. The research study indicates that in serviceoriented companies, consulting types of services are highly value adding, and margins are often
high. Another conclusion is that the innovation and learning impact from consulting; based on the
research results, influences the activity system of the company to enhance its deliveries. Authors
claim that consulting activities are often used to enhance the relationship and create a trust base
for larger and profitable activities. According to the authors, services companies maintain and
sustain their relationships with their customers by the marketing activities such as: inviting small
groups of top CIO’s to so called “discussion circles”, where they can address and exchange their
concerns and ideas, sharing implementation risks with the customers, demonstrating their
commitment to complete the project successfully and publishing articles and books to prove their
expertise. According to (Alajoutsijarvi et.al, 1999), project business applies the relational
marketing approach, in which the customer and supplier organizations form strong social
economic, technical, and legal bonds over time in order to achieve mutual benefit.
Another service type that plays an important role is the maintenance type of services, which do
not refer only to maintenance but also to operations support, outsourcing and other types of
33
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
services that relate to operating and developing the existing installed base. Based on the
observations of the authors, the maintenance types of services are extensive both in number and
volume. Artto et.al (2008) conclude that the role of core projects and core product technology
may be to indirectly support the firm’s technological advancement that enables an even more
worthwhile business that relates to the installed base and maintenance types of services.
From a project-based firm perspective, Gann and Salter (2000) focus on the relationships
between firms’ core technical capabilities and the projects, in which they work. They analyze how
firms build links between operations at the project level, portfolios of projects, and central routine
activities. Winch (1998) states that the management of business processes associated with
projects is a generic business process in construction. With the term construction, it is meant
“designing, maintaining and adapting the built environment, involving many organizations from a
range of industrial sectors, temporarily working together on project-specific tasks”. Gann et.al
(2000) describe the main characteristics of project-based firms in construction as follows:
 Their design and production processes are organized around projects
 They usually produce one-off, or at least highly customized products and services and,
 They operate in diffuse coalitions of companies along the supplier-customer chain.
Gann et.al (2000) developed the following model indicating the interactions within which technical
support and service activities at a project-based and service-enhanced firm can be explored:
Figure 8: The project-based firm and technical resource flow (Gann et.al, 2000)
Figure 8 illustrates in-house support and external research and technical support services
bought-in by firms. Knowledge associated with “know-what” and “know-why” tends to be codified,
while knowledge associated with “know-who” and to some extent “know-how” tends not to be
34
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
codified, or tacit. The authors discuss that tacit knowledge may be extremely important in a
project-based and service-enhanced firm in the provision of design and other services.
4.3.5. User involvement
McConnel (1998) states that user involvement is significantly important and provides advantages
to the software project team because it eliminates one large source of requirements changes.
The author states that, “If the users aren’t involved early on, when they are brought in to review
the software late in the project, they can identify the ways in which the software has fallen short of
their needs. At that point, the development team is confronted with a difficult choice; ignore the
user input and adhere to budget and schedule, or act on the user input in the downstream
(development) part of the project and throw the budget and schedule out of window”.
Based on an in-house development at the project-based companies, Grudin (1991) supports the
statement of McConnel (1998) and states that it is an advantage to know users and developers
from the beginning of the project. The author identifies some opportunities in the internal software
development project. Some of the opportunities that are identified are ‘strong top management
support, communication between developers and users based on a shared corporate culture and
the smoothness of the transition across the development phases (The developers are accessible
during product introduction and use).
According to (Sawyer, 2000), developers at service companies are part of the corporate staff and
serve supporting roles. The development focus is on the process, which means that these
companies follow an ad-hoc approach to develop their software (Humprey, 1989).
4.3.6. Software development
Software development project management consists of upstream and downstream parts.
Upstream part refers to the early parts of a project such as requirements development and
architecture; downstream part refers to the later parts such as construction and system testing.
Effective planning is necessary to run the software development projects since the average
project in the reality spends about 80 percent of its time on unplanned work and rework – fixing
mistakes that were made during the early stages of the project (McConnel, 1998).
According to McConnel (1998), software project management consists of a software development
plan, which maps a course for the projects and project estimates, and provides a foundation for
project plans. In this sense, a careful estimate leads to scoping the project appropriately, which in
turn leads to budgeting, staffing and scheduling the project appropriately; Revised estimates,
which allow for mid-course corrections and help to keep the project on solid footing; A Quality
Assurance Plan, which includes both technical reviews and testing assures that the project will
35
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
not succumb to a costly defect-ridden test, debug and correction cycle; A staged delivery plan,
which defines the order in which the software will be constructed. This last one ensures that the
software solution is developed to both maximize the value to the customer at each stage and
minimize the risks to the project.
McConnel (1998) identifies also the other major planning activities such as Requirements
development, which identifies in detail the problem that the project team is trying to solve. This
amounts to planning to solve the right problem. Architecture, which is a high level specification for
the way in which the problem will be solved is a plan to build the right solution to the problem and
detailed design, which includes a comprehensive plan of what the project is going to build. It is a
plan to build the right solution at the right way.
According to Grudin (1991), there are obstacles identified during the custom software
development. One of the obstacles that the author mentions is that the management or
information systems staff can have conflicts in the interests with the end users; another obstacle
is related to the friction between the developers and users. This can result from differing codes of
values, conduct, and dress, as well as disparities in age and salaries.
Grudin (1991) presents the developer and user populations known at the project outset as
follows:
Figure 9: In-house and custom development: Developer and user populations (Grudin, 1991)
36
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4.3.7. Reusability in software development
Schach and Tomer (2000) state, that “in classical software engineering, a characteristic of
development is that the development team builds the target software starting from scratch”. Since
the software construction brings high costs, developers nowadays try to utilize existing software
artifacts wherever possible. In this sense, Schach and Tomer (2000) mention that “if a customer’s
requirement for a target product has been implemented in an earlier product, then it should be
possible to reuse the specification, design, test cases, documentation, code, and all the other
artifacts associated with that requirement in the new product”. According to the authors, this
refers to ‘Software product lines’, which are “a set of software-intensive systems sharing a
common, managed set of features that satisfy the specific needs of a particular market segment
or mission” (Clements and Northrop, 1999).
Crnkovic (2001) identifies some challenges in software development projects such as failures to
meet the deadlines, budget, quality requirements and the continued increase in the costs
associated with software maintenance. That’s why Crnkovic (2001) claims that component-based
engineering is the key approach to consider meeting the identified challenges. In componentbased approach, software systems are built by assembling components already developed or
prepared for integration. The authors state that component-based engineering can be used in
different lifecycle models. The following figure shows the waterfall model using component-based
engineering:
Figure 10: The development lifecycle compared with waterfall model
37
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Based on the Figure 10, Crnkovic (2001) identifies the following steps for a component-based
development process:
 Find components, which may be used in the system: All possible components should
be listed for further investigation. A vast number of possible candidates must be available
as well as tools to find them.
 Select components, which meet the requirements of the system: often the
requirements cannot be fulfilled completely and a trade-off analysis is needed to adjust
the system architecture and to reformulate the requirements to make it possible to use
the existing components.
 Adapt the selected components so that they can suit the existing component
model or requirement specification: It would be possible to integrate some
components directly into a system, some of them would be modified through
parameterization process, and some would need wrapping code for adaptation.
 Compose and deploy the components using a framework for components: typically
component models would provide that functionality.
 Replace earlier with later versions of components: this corresponds with system
maintenance. Bugs may have been eliminated or new functionality added.
4.3.8. Service business benefits
In general terms, there are benefits attached to companies that follow a strong service-oriented
approach. Lynn et.al (2000) state for example that following a service oriented approach from a
strategic point of view leads to increases in profit, growth, customer satisfaction and loyalty. A
company’s profit, growth, customer satisfaction and loyalty are enhanced by organizational
service orientation; that means following organizational policies, practices and procedures that
support service excellence (Lynn et.al, 2000). In this sense, companies can create competitive
advantage over its competitors (Doyle and Wong, 1998; Jones and Sasser, 1995).
Galbrait (2002) analyses several well-managed companies from a customer-centric point of view.
According to the author, companies following a solutions strategy bundle their products together
and add software and services. These packages create more value than the customers can
create for themselves by buying only the stand-alone products.
38
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4.3.9. Overview of service business characteristics
In this section, we will present all the characteristics of service-oriented business found during the
literature study into below table with the purpose to give complete overview of how service
businesses operate based on certain dimensions.
There are four perspectives defined: Societal, Marketing & Sales, Company and Development
perspective. Societal perspective concerns the dimensions, which characterize both types of
businesses to manage the internal factors such as: work culture, type of organization, rewards,
approach to the personnel, team characteristics and external factors such as intellectual property
rights, nature of markets, integrating technology.
Marketing and sales perspective concerns the dimensions, which deal with organization’s
strategy on its target market firstly to identify needs/wants and secondly to leverage distribution of
products and/or services and to grow the organization in a competitive society.
Company perspective concerns the dimensions that characterize both types of companies in the
way of their operating as a whole business. These dimensions include companies’ business
focus, business model, their central capabilities, value creation route etc. Finally development
perspective concerns the dimensions such as development goal, development process, user
involvement etc. (see further in table 5).
39
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Dimensions
Societal perspective
Intellectual
Service businesses pay less attention on Intellectual Property Rights (IPR). Mostly, they do
property rights
not see the added value of whatever service they have delivered to their customers
beforehand. Because service businesses are knowledge-intensive businesses, the most
important intellectual property lies in their employees. In this sense, some service
businesses follow loyalty-building strategies with their key employees to protect the
intellectual property (Päällysaho and Kuusisto, 2008).
Work culture
The work culture at service companies is bureaucratic and based on long-term relationship
management with the customers. Service companies operate thus their business
bureaucratically, which means that there are organizational policies, goals and rules that
people follow at these types of companies. Relationship with the customers is very
important. In this sense, employees at service companies manage and maintain their
relationships with customers by promoting solutions and even running the customers’
networks. By knowing customers’ business, the purpose is to identify more and more
customer needs and achieve long-term relationship (Galbraith, 2002).
Nature of markets
The nature of markets, where service companies operate is based on collaborative
relationship or even a hierarchy in the form of vertical integration, in which the customer and
supplier organizations form strong social, economic, technical and legal bonds over time in
order to achieve mutual benefit. In this sense, service companies operate in a familiar local
closed and networked market (Alajoutsijarvi, et.al, 2010). At companies that provide custom
information systems solutions to their customers, the cost is almost always paramount. In
information systems, the trade-offs between schedule (time) and resource/budget are seen
as key aspects of project management (Boehm, 1987) and cost is considered a major risk
and a critical measure of project success (Boehm, 1991). Thus in the market, where service
companies operate, there is also a cost pressure to be considered.
Type of
Service businesses follow more an “Ad-Hoc” approach in their project management;
organizations
especially the developers serve these companies supporting roles and believe in the
importance of process and in this sense an ad-hoc approach is followed to develop a certain
solution (Humprey, 1989, Sawyer, 2000). When the companies follow an “ad-hoc” approach,
there are certain deadlines to finish a specific solution but they don’t stick to any plan. If
testing for a software program is performed for example, and if the time assigned to test the
program is less (say, it must be done in certain amount of time), then ad-hoc approach is
applied. In this sense, service companies are “Ad-Hoc” project organizations.
Rewards systems
At service companies, “the larger the scale of a solution, the more complicated is the
measurement of service business unit performance and the pricing process” (Galbraith,
2002). Reward systems at service companies tend to focus more on company performance.
Approach to
Because service companies focus on customers’ network and the way their customers run
40
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
personnel
their business, rewards are given to people with in-depth knowledge of customer’s business.
Galbraith (2002) states that relationship managers, who save the customers’ business, get
the highest rewards for example.
Team
One of the team characteristics is that project teams at service companies are matrix
characteristics
managed (Sawyer, 2000), which means that employees are pooled for work assignments or
to concentrate on specific tasks. In a matrix organization, employees are treated as shared
resources between managers and may have to work under multiple managers
simultaneously. Managers have the responsibilities for employees shared on specific
projects as well as sharing manpower for several departmental functions (Mehrmann, 2007).
Another characteristic is that the teams follow a structured project-focused approach and
work in a collaborative way since the projects at service companies are tied to certain
scheduling and budget on the customer side.
Dimensions
Marketing & Sales perspective
Marketing goal
Service companies don’t reserve any budget for marketing activities (Hoch et.al, 1999) but
lifetime value of customers is central focus; this means that the activities such as customer
retention and service recovery efforts are performed to manage the existing customers, the
purpose behind this is also to build more cooperative and long-lasting relationships with those
existing and potential customers (Fornell, 2002). Performing these activities leads to winning
the trust and loyalty on the customer side.
Foreign market
For a foreign market entry, service companies focus more on the character and number of
entry
business relationships they developed with other firms in the foreign network as well as with
the actors that are active in the development of these relationships (Alajoutsijarvi, et.al, 1999).
When entering a foreign market, cultural distance may influence for example the entry mode
selection of service companies, which may then lead to uncertainty in their definition of
strategy to internationalize (Kought & Singh, 1988).
Differentiation
This dimension deals with the way that service companies build and maintain their relations
with their existing and potential customers relative to their competitors in the same market
segments. Since relationship management is an important focus area for service companies,
they follow relationship differentiation strategies (Alajoutsijarvi, et.al, 1999). One of the
initiatives service companies take for example is to invest in Customer Relationship
Management (CRM) tools to know the customer thoroughly based on its core business and
assets and in this way to develop strategy that may differentiate them from their competitors.
Market interaction
Since the service companies provide customer specific solutions, there is an interactive
communication between the involved parties (for example: supplier and customer). Whether it
is a system implementation or consulting for a specific project, the parties that interact with
each other share knowledge, learn from best-practices and adapt themselves to situations
based on social, economic, technological and legal factors. In this sense, all the interaction
41
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
parties play an active role on the market (Alajoutsijarvi, et.al, 1999).
Negotiations
Negotiations are crucial for service companies in their management of relations with their
existing and potential customers based on SLA’s, project planning and budget (Alajoutsijarvi,
et.al, 1999). One of the important negotiations that happen at service companies is for
example bidding process, which is a recognized way of competing with other businesses for a
contract to do a project. The hiring customer examines and compares bid proposals from the
different businesses to choose the company with the best overall proposal (Cyprus, 2012).
Identification of
Service companies are more customer-oriented and they deliver only solutions based on the
most customers
specific wishes of the customers. There is firstly an active search to the needs of existing
customers or to identify new customers on the market with the purpose to get new projects
arranged. In this sense, service companies do not take initiatives to develop a software
product internally and then bring that product to the market such as the product companies do.
Firstly customers are identified and then solutions are implemented based on customer
specific wishes (Keil and Carmel, 1995), (Grudin, 1981).
Customer base
Service companies aim to know their customers’ business thoroughly and base their
relationship on a long-term. In this sense, the customers that service companies do business
with are well-known customers (Alajoutsijarvi, et.al, 1999). The situations, where two parties
build a strong bond and a mutual benefit with each other are the interactions that take place
during project implementations (customer-developer links for example in the sense that they
both are physically at the same location and interact with each other intensely based on the
project requirements (Keil and Carmel, 1995).
Number of
Service companies target on specific customers in certain market segments. In this sense, the
customers
number of customers can be one or more (Keil and Carmel, 1995). (Alajoutsijarvi, et.al, 1999)
state that most European software firms that deliver service-intensive customer projects
concentrate almost solely on serving their home markets instead of operating at the
international markets. In this sense, this can also be the factor that service companies have
certain number of customers on specific market segments.
Sales bias
Service companies are always on the side of customer in the transaction, which means that
every solution provided to the customer is for his benefit. Galbraith (2002) gives the example
such as: “The outsourcing and consulting service at IBM will suggest a Hewlet Packard server
if it makes more sense for the customer. In order to maintain the credibility with the customer,
the people from the services business must not be biased toward IBM equipment. They must
be on the side of the customer in the buyer-seller transaction”.
Returns of Scale
Returns from scale matters the inputs and outputs of a firm’s production function. There are
constant, increasing or decreasing returns to scale depending on the quantity produced in a
firm versus the total cost structure. Returns to scale measure mainly the cost-effectiveness of
a firm. Nabisan (2001) states that a variable cost structure at service companies makes
42
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
increased returns from scale rare, especially when all input levels are also variable.
Dimensions
Company (Organizational) perspective
Business focus
The overall business focus at service companies is to deliver customer specific
solutions/services with the purpose to meet the needs of the customers within budget and
time. These solutions/services are thus implemented based on contractual agreements. The
concrete goals to achieve are customer satisfaction, acceptance and Return on investment
(Cusumano, 2004; Galbraith, 2002; Keil and Carmel, 1995).
Business model
Business model at service companies is based on the sales of services such as
development, maintenance, support and implementation, strategy advice, training, and
system integration. In this sense, the service content is quite high and since these types of
services are applied differently at each customer considering the clear and lengthy costs in
terms of labour, the marginal costs become also relative high (Hoch et.al, 1999, Coloumbe,
2000; Artz et.al, 2010).
Value creation
At service companies value is created from customizing for the best total solution on the
route
customer side, personalized packages of service, support, education and consulting. By
using its resources more effectively, service companies can increase benefits to their
customers (Galbraith, 2002).
Production
The service companies deliver its services to its customers when a contractual agreement is
signed (after the sales process has taken place) between both parties and in this sense;
after signing the contract, production consists of all the activities within and during the project
(Alajoutsijarvi, et.al, 1999).
Central capability
The central capabilities of service companies are project marketing, client management and
project management. From the marketing perspective, service companies promote for
example their projects, which are already implemented at their existing customers, to the
potential customers in certain market segments. The customer references play an important
role in this.
Nature of
Interactive, mutual, multi-facetted, long-term oriented, project related exchange
exchange
(Alajoutsijarvi, et.al, 1999).
Mental process
The mental process of service companies is based on convergent thinking: what
combination of products/solutions is best for the customer? This means that, when delivering
solutions/services to the customers, the aim is to increase the benefits of the customers. By
having deep insight in the customer’s network and the way the customer operates its
business, service companies identify more and more needs to satisfy the customers
(Galbraith, 2002).
Most important
Most profitable, loyal customer, which means that there is a long-term relationship
customer
maintained with the customers (Galbraith, 2002).
Most important
Customer relationship management since service companies are customer-oriented and
43
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
process
focus only on the customer needs (Galbraith, 2002).
Organizational
The organizational concept is surrounded by customer segments, customer teams, customer
concept
P&L’s, where the customers’ potential profit is the central focus to service companies.
(Galbraith, 2002).
Measures
Customer share of most valuable customers, customer satisfaction, lifetime value of a
customer, customer retention (Galbraith, 2002).
Common types of
New system project; “Maintenance” enhancements, system integration (Keil & Carmel, 1995,
projects
Artz et.al, 2010).
Project lifecycle
Lifecycle of a project at service companies is usually at the first stage of the development,
implementation or integration of a system and/or solution and later maintenance with the
purpose to maintain long term relationship with the customer ((Bergström and Dahlqvist,
2007, Artz et.al, 2010).
Delivery
Service companies sell principally knowledge, in this sense, software professionals
(developers, testers, consultants) from different knowledge domains are delivered to the
customers based on project basis (Koenig, 2005; Cusumano, 2004).
Valuing
Projects can be valued after they are already implemented and delivered to the customer
(Hoch et.al, 1999).
Abstracting
Knowledge abstraction at service companies is not important. Knowing client’s
knowledge
idiosyncrasies (structural characteristics) is more important than knowledge abstraction
(Nabisan, 2001).
Product
This dimension matters the products that complement each other in the sense that if one is
complementarity
bought, that the other kind of product becomes also necessary to buy. Service companies do
not pay much attention to product complementarity since they get their revenues by selling
their knowledge in different domains (Nabisan, 2001).
Dimensions
Development perspective
Development goal
Service companies develop custom software solutions on the customer side based on their
specific needs. Principally, it is not a goal for service companies to develop a software
product internally and sell it to a certain market or group of specific customers (Keil &
Carmel, 1995, Artz et.al, 2010).
Development
Development process is mature; there is separated design and development phase. Design
process
control is done via consensus building (Sawyer, 2000, Artz et.al, 2010).
Requirements
Service companies manage projects separately per specific customers, which means that
elicitation
from the requirements management perspective, all the requirements are gathered and
elicited from the specific customers (Bergström and Dahlqvist, 2007, Artz et.al, 2010).
Requirements
Requirements specification is a formal document that collects the specified requirements for
specification
a system. This document often forms a basis for the contractual agreement between the
service company and the customer (Bergström and Dahlqvist, 2007, Artz et.al, 2010).
44
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
User involvement
During the software development project, user is close and more involved (Sawyer, 2000).
Again from the development perspective, it is significantly important to involve users with the
purpose to eliminate one large source of requirements changes so that the developers can
prevent shortcomings to the needs on time (McConnel, 1998).
Software
User, End-user (Keil & Carmel, 1995, Artz et.al, 2010).
consumer
Physical distance
Usually small (e.g. customers are in the same building as developers) (Keil & Carmel, 1995,
between user and
Artz et.al, 2010).
developer
Connection with
Companies have project-driven relationships: typically users are technologically
users
unsophisticated. (Nabisan, 2001)
Table 5: Overview of Service business characteristics
45
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4.4. Product business characteristics
The software products business is mainly about economies of scale, which means volume sales;
selling or licensing the most copies of a standardized product as you can. The basic growth
strategies here are scaling or duplicating what you have done in similar markets (Cusumano,
2004). Hietala, Kontio, Jokinen and Pyysiäinen (2004) define software products companies as
“Companies that can package and replicate their software offering”. A software product is defined
by (Xu and Brinkkemper, 2005) as “a packaged configuration of software components or a
software-based service, with auxiliary materials, which is released for and traded in a specific
market”. One of the unique characteristics of software as a product is that once it is developed, it
can be replicated at close to zero marginal costs (Messerschmitt and Szyperski, 2003; Shapiro
and Varian, 1998). In his book “Business Software”, Cusumano gives the example of Microsoft,
which became for example the market leader through its volume sales and set de facto technical
standards that have “locked-in” customers because their software applications and databases
work on a particular operating system or hardware platform.
Focus at product-oriented companies is on research and development to build product software
and once the software product is ready to be delivered, the focus shifts to sales; selling millions of
copies of a certain software package to a certain market (Cusumano, 2004; Hoch et.al, 1999).
From a marketing and sales perspective, the primary goal of product companies is to market their
brands and products (Nies, 2005). Marketing begins at the product-oriented companies in the
product development stage (Sink, 2006).
Based on the case-study results, Sawyer (2000) reports that time pressure dominates product
software development industry. The pressure to create return on investments leads to intense
attention at bringing both new and innovative products. At product software companies, product
reviews are also of great importance in the sense that the awareness of the product remains in
the minds of the target market. Sawyer (2000) points out that once the product software is a
‘breakthrough’ product or a “killer app” as Cusumano (2004) calls, the product companies can
develop a large installed base or create new markets.
Pelham (2000) claims that companies with strong product orientations favor efficiencies and cost
minimization with respect to decision-making. The companies realizing the benefits of strong
product orientation focus mainly on product efficiencies, cost minimization and mass distribution
(Kaufman, Luciano and Humphries, 2002). Voss et.al (2000) state that besides product efficiency
and cost minimization, product orientation involves a company’s new product development and
marketing process. Alajoutsijarvi et.al (1999) state that product business applies marketing mix
46
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
approach, in which the customer and seller focus on the short-term exchange of basic products in
a highly competitive market.
From the capabilities perspective, Cusumano (2004) states, that software products companies
organize themselves around product teams that target specific competitors or customer
segments. Products companies focus usually on product development for general users in their
market unless they are in very small niche markets.
Software product companies can deliver their packaged software to the global market easily since
their product is generic and can be customized for specific markets (e.g. changing language and
currency settings) without changing the core functionality of the software. Only challenge that a
software product company can have is how to make the product offering so generic that it meets
100 % the needs of the customers (One size fits all principle) (Koenig, 2005). Once the software
product is developed and is ready for the global market, the focus is then on global marketing and
mass customization.
From a work culture perspective, Sawyer (2000) states that product software companies are
entrepreneurially oriented (due to low entry and exit barriers in this industry). According to the
author, product software development teams are smaller and co-located.
4.4.1. Business model
Software companies with product orientation gain most of their revenues from the sales of
packaged software. Writing a software package requires for a product software company maybe
a large investment however marginal costs of making copy of a CD is very insignificant.
According to (Coloumbe, 2000), the software industry can be seen as one of the few industries, in
which the marginal cost of production is very low. Coloumbe (2000) states that “gross profit
margins in the airline industry are for example approximately 5 percent, while gross margin in the
software industry is about 90 percent”.
Hoch et.al (1999) state that, “there are in the product business low entry barriers to a certain field,
where knowledge is more important than cash and equipment”. According to the authors, the
product business is 95 % intangible capital. Low capital investment is enough to start a product
business company. Hoch et.al (1999) refer to the statement made by the founder of Trilogy Joe
Liemandt: “In fact, you want as little money as possible, that forces to be efficient”. In this sense,
software product companies are usually much more attractive to stock market investors and
venture capitalists because of their potential for growth and profits (Hoch.et.al, 1999; Cusumano,
2004). Hoch et.al (1999) discuss also that low financial requirements in the software product
business lead to faster innovation and technological breakthroughs, as many start-up players join
47
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
the market, compete and strive for innovation. In addition, Leonard-Barton (1992) points out that
focusing too much on customers (marketed-oriented approach) can prevent the product
companies to innovate and develop new products. The authors suggest that it may be better to
ignore customers through the research and development and new product development
processes.
Cusumano (2004) states that a products company should have well over half its revenues
(around 60 per cent) coming from new sales of software products (software license fees,
excluding product update fees included as maintenance or product support). Based on the
research results on the software product companies in Finland, Hietala et.al (2004) show the
percentage of company’s own software product business revenue from the overall company
revenue as shown in Figure 11:
Figure 11: Companies' total revenue acquired from software product business (Hietala et.al, 2004)
The results show that almost 60 % of the companies acquire their total revenue out of software
business. Small decrease in the share of software product business revenue can indicate that
some product companies orientate themselves also to project business in order to generate
revenue when product business suffers from the economic situation such as decrease in the
product sales (Hietala et.al, 2004; Cusumano, 2004).
There are eight possible improvement areas defined by (Hietala et.al, 2004), in which product
companies are focusing as shown in Figure 12:
48
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Figure 12: The most important improvement areas at Product companies (N=122) (Hietala et.al, 2004)
The research results show that 56 % of the companies rate product development or
productization as the most important or the second most important improvement area.
Improvement of personnel knowledge and networking and co-operation were also quite often
ranked as important improvement areas.
Cook (2005) points out that product-oriented companies consider the distribution channel as the
most important aspect based on their business model and strategy. Microsoft works for example
closely with its hardware complements, such as Intel, and PC manufacturers, such as Dell and
Compaq for the sales channels (Cusumano, 2004).
4.4.2. Software Product Management (SPM)
Van de Weerd, Brinkkemper, Nieuwenhuisen, Versendaal and Bijsma (2006) developed a
reference framework that reflects the software product management processes in product
companies. The authors point out that, “There are certain artifacts for product companies to
consider in their product management practices such as requirements, products and releases. A
hierarchical ordering of these artifacts imposes a structure on the process areas. The scope of
work of product management starts with the complete set of products of the product company,
the so-called “Product portfolio”. The product portfolio can consist of many products or just one
product depending whether the company is small or large. Each product has a release sequence
of past, present and future releases. Finally each release definition consists of a set of selected
requirements. Each requirement implies the addition of a technical or functional feature to the
product. According to Van de Weerd et.al. (2006), the process areas for a software product
management concern Portfolio management to deal with the products in the product portfolio;
Product road mapping to deal with the different releases of each product; Release planning to
deal with the collections of requirements of each release and Requirements management to deal
with the content of each individual requirement.
49
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4.4.3. Organization and development perspective
“From an organization perspective, a product company will develop its corporate strategy, product
strategy and service strategy according to its target market. The product and service strategies
are in service of the corporate strategy. Process and quality control provide an overview to the
production process and guarantee certain level of quality. From the development perspective, the
product software includes requirements engineering, architecture/design development, delivery
and implementation services stages” (Xu and Brinkkemper, 2005).
Based on the product development framework (Figure 14) by (Xu and Brinkkemper, 2007),
requirements management in a product company deals with capturing all the market
requirements relevant for the product. Those market requirements are implemented in certain
releases and brought up on the target market at the right time. Another important area in the
development of product is the software architecture, which “codifies the structural commonality
among a series of software products so that the high-level design decisions inherent in each
product need not be re-invented, revalidated or re-described”. The delivery of software product
means that it is launched and offered to the market. In this sense, there are two important
aspects to consider: Configuration management and documentation. Configuration aims to keep
evolving software products under control and help satisfy delay and quality constraints. Software
documentation describes the requirements of the software products, which need to be satisfied,
the design, implementation, capabilities and limitations of the software product to make the
product easier to use, maintain and reuse.
Figure 13: Software product development framework (Xu and Brinkkemper, 2007)
50
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Sawyer (2000) states that developers at product software companies hold “line positions”, which
means that the needs of those developers are central to the performance of the organization.
Product software developers have also distant relationships with their user population. In this
sense, consultants or helpdesk personnel link users to developers. According to Sawyer (2000),
product software companies have a product (not process) view of development, which means
that shipping of the product is the main goal and all other activities are secondary.
The development approach at product software companies is iterative, flexible and constantly
evolving, which underscores Microsoft’s “Sync-and-Stabilize” method that Cusumano (1997) has
documented.
51
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4.4.4. Overview of product business characteristics
The same overview as the one on service-oriented business is also given for the product software
business based on the same perspectives as follows in table 6:
Dimensions
Societal perspective
Intellectual
Product software companies pay much attention on Intellectual Property Rights (IPR). When
property rights
there is a software program developed, which serves to a certain market needs, it is crucial
for a product software company to apply IPR on it. In this sense, product companies are alert
to protect their IPR’s with patents, copyrights, trade secrets or trademarks (Nabisan, 2001).
Work culture
Product software companies are entrepreneurial-oriented, which means that people in the
organization are innovative to develop new products and open to new technologies and/or
ideas (Sawyer, 2000, Galbrait, 2002).
Nature of markets
When developing software programs or systems at product software companies, these
programs or systems serve either to a certain segment in home market or in the international
markets, where there is a high competition due to commodities or disruptive new
technologies. Time to market plays a crucial role as product software companies operate
their business in a competitive environment (Alajoutsijarvi, et.al, 1999, Sawyer, 2000).
Type of
Product software companies are very much market-oriented, which means that they identify
organizations
the market needs and based on that, they develop products instead of focusing on specific
customer needs. Product software companies are also matrix organizations, where product
development processes are managed properly (Alajoutsijarvi, et.al, 1999).
Rewards systems
Rewarding is based on business unit performance (Galbraith, 2002). According to Sawyer
(2000), there are big financial rewards for the software development team members. In his
research, he gives the example that stock options and performance bonuses create 17
millionaires per week at Microsoft.
Approach to
At product software companies, Research and Development department plays a crucial role
personnel
to develop software products. In this sense, rewards, more flexibility and freedom are usually
given to the developers (Galbraith, 2002).
Team
Less likely to have matrix/project structure, more likely to be self managed, people are
characteristics
involved in the entire development cycle, more cohesive, motivated, there are opportunities
for large financial rewards and people share a vision of their product (Galbraith, 2002).
Dimensions
Marketing goal
Marketing & Sales perspective
The marketing goal at product software companies is to manage the company’s product
portfolio and to achieve 4P’s (Product, Price, Place and Promotion). Marketing is based purely
on transactional relationship, in which “the customer and seller focus on the short-term
exchange of the basic products in a highly competitive market. This approach is called
“Marketing mix management”, where 4P decisions are important for competing for the
52
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
preferences of the chosen target segment of consumers or organizational buyers”. Product
software companies consider branding and image also as an important marketing goal
(Alajoutsijarvi, et.al, 1999; Hoch et.al, 1999; Nies, 2005).
Foreign market
For the foreign market entry, an important aspect that product software companies consider is
entry
the choice of product/market, thorough analysis that is performed before entering a certain
foreign target market such as target customers, competitors or trade barriers etc. After having
defined the goals and the choice of entry mode for the target market, developing a marketing
plan for penetration and creation of control systems for monitoring of needs of the defined
market are also one of the important aspects that product software companies consider
(Alajoutsijarvi, et.al, 1999).
Differentiation
Product differentiation (Alajoutsijarvi, et.al, 1999). Product software companies follow different
product differentiation strategies to create competitive advantage on the market they operate.
These strategies are e.g. differentiating products on unique technical features (such as
specialized user-interfaces or connectivity/compatibility features), brand names, service
customized to specific user groups or products, or some combination of these (Mosakowski,
1993).
Market interaction
There is one-way communication. Formal market studies are performed to identify the market
needs. Seller is the active counterpart (Alajoutsijarvi, et.al, 1999). In general terms, when the
products are developed, they are usually delivered to a certain market. Before delivering the
product to the market, some product companies take user groups to test the product(s) on
bugs and certain functionalities.
Negotiations
Negotiations are not seen as important (Alajoutsijarvi, et.al, 1999). From the entrepreneurial
perspective, the aim is to identify a certain need on the market, to develop it and to bring it on
the market. In this sense, product software companies are not dependent on the negotiations
with for example specific customers or group of customers.
Identification of
Most of the customers at product software companies are identified after development ends
most customers
and the products go to market (Keil & Carmel, 1995), (Grudin, 1991).
Customer base
The customers product companies focus on matter broad, faceless end customers.
(Alajoutsijarvi, et.al, 1999). In this sense, the products are usually standard and serve to the
needs of markets (whether it is the home or international market), where there is no direct
interaction with specific customers.
Number of
The number of customers can rise up to millions of users (customers) since product software
customers
companies target on certain markets (Keil & Carmel, 1995). A good example is Microsoft that
develops standard products, which are used by millions of users or customers internationally.
Sales bias
Sales bias at product software companies is on the side of seller in the transaction. As an
example, A server salesperson at IBM is on the side of seller: the product centric server
business (Galbraith, 2002).
53
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Returns to scale
As mentioned earlier, returns to scale depends on the quantity produced in a firm versus the
total cost structure. In this sense, Nabisan (2001) states that a fixed cost structure allows for
higher returns from scale at product software companies.
Dimensions
Business focus
Company (Organizational) perspective
The business focus at product software companies is mainly based on research and
development with the aim to gain market share and to make profit in the target market. The
people working at product software companies share common mind share to provide the
best product for the customer/market (Cusumano, 2004; Bergström & Dahlqvist, 2007,
Galbrait, 2002, Sawyer, 2000, (Keil & Carmel, 1995, Artz et.al, 2010).
Business model
Product software companies get their revenue through the sales of packaged/modular
software products, where the marginal costs are low. Service content is also lower compared
to the one at software service companies (Coloumbe, 2000; Hoch et.al, 1999, Alajoutsijarvi,
et.al, 1999, Artz et.al, 2010).
Value creation
Product software companies create value from cutting-edge products, useful features and
route
new applications. This means developing (disruptive) technologies/solutions that serve a
certain market, where there is little or no competition (Galbraith, 2002).
Production
Production at product software companies involves the activities to develop the software
products internally, based on the identified market needs and then the next step is to deliver
the product to the market. Once the product is in use on the market, product software
companies maintain their products through the updates or new versions or releases. In this
sense, production is performed before sales and production function operates rather
independent from other company functions (Alajoutsijarvi, et.al, 1999)
Central capability
The central capabilities of product software companies are Productization, channel
management, alliance building strategic partners in the industry, global marketing and mass
customization (Alajoutsijarvi, et.al, 1999, Cusumano, 2004).
Nature of
Opportunistic, short-term oriented, product-related exchange (Alajoutsijarvi, et.al, 1999).
exchange
Mental process
Divergent thinking: how many possible uses of this product are there? Product software
companies aim to reach as many users as possible to gain more market share (Galbrait,
2002).
Most important
Most advanced customer/user (Galbraith, 2002).
customer
Most important
New Product Development (NPD), which includes the process to bring a software product to
process
market (Galbrait, 2002).
Organizational
The organizational concept of product software companies is surrounded by product profit
concept
center, where most of the profits are likely to come from (e.g. the major profit centers of
Microsoft are Windows operating system and Microsoft Office software), product reviews,
54
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
which are essential to have for the maintainability of the software product, product teams
that develop the products (Galbrait, 2002).
Measures
Number of new products, Market share (Galbraith, 2002, Artz et.al, 2010).
Common types of
New products; new versions (major and minor) (Keil & Carmel, 1995, Artz et.al, 2010).
projects
Product lifecycle
The product lifecycle is based on incremental releases at product software companies,
where new changes and bug fixes are implemented (Bergström and Dahlqvist, 2007, Artz
et.al, 2010).
Delivery
Global marketing and mass customization. Software product companies can deliver their
packaged software to the global market easily since their product is generic and can be
customized for specific markets (e.g. changing language and currency settings) without
changing the core functionality of the software. (Koenig, 2005; Cusumano, 2004).
Valuing
The product software can be valued before the purchase of the product by reading the
product reviews or comparing the product with other products based on price, features etc.
(Hoch et.al, 1999).
Abstracting
The product software company must be able to gather generic product knowledge so that
knowledge
the product can be used in a variety of contexts (Nabisan, 2001).
Product
Product complementarity is very important since a certain software product can necessitate
complementarity
to purchasing certain hardware to run the product on (Nabisan, 2001).
Dimensions
Development perspective
Development goal
Software developed for external use (i.e. sale) (Keil & Carmel, 1995, Artz et.al, 2010)
Development
Software development process at product software companies is immature since the
process
developers also tend to have a product (not process) view of development (Carmel, 1995).
“A product focus means that the dominant goal of software development effort is to ship a
product and all the other activities are secondary. There is somewhat integrated design and
development with a high iterative, flexible and constantly evolving process” (Sawyer, 2000).
Requirements
Requirements are elicited based on the market needs (Bergström and Dahlqvist, 2007, Artz
elicitation
et.al, 2010).
Requirements
Central database is used to store the requirements (Bergström and Dahlqvist, 2007, Artz
specification
et.al, 2010). One reason for this is that requirements at product software companies need to
be managed individually rather than in specifications, as requirements are not strictly
dedicated to a specific development project (Higgins, de Laat, Gieles, & Geurts, 2003).
Another reason lies in the fact that the number of requirements is typically large and
continuously growing (Gorschek and Wohlin, 2006).
User involvement
Since product software companies bring products for markets, user is distant and less
involved (Sawyer, 2000; Artz et.al, 2010).
Software
Customers (Keil & Carmel, 1995, Artz et.al, 2010).
55
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
consumer
Physical distance
Usually large (e.g. customers are spread worldwide) (Keil & Carmel, 1995, Artz et.al, 2010).
between user and
developer
Connection with
Companies have long-term relationships: typically users are technologically sophisticated
users
(Nabisan, 2001).
Table 6: Product business characteristics
4.5. Differences between service and product businesses
In this section, Figure 14 shows all the dimensions identified for both types of businesses, mainly
software service and product software business with the corresponding perspectives. Each
perspective includes thus the dimensions, which are managed differently by both types of
businesses and these dimensions influence both types of businesses in their way of operating.
Figure 14: Characteristics between service and product business
Table 7, the characteristics of both types of businesses are displayed in a comparison based on
the identified dimensions:
56
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Societal perspective
Dimensions
Service business
Product business
References
Law and
Intellectual property rights less
Intellectual property rights
(Nabisan, 2001)
regulation
important
very important
Work culture
Bureaucratic, Relationship
Entrepreneurial, New product
(Sawyer, 2000,
management culture, Searching
culture, open to new ideas,
Galbrait, 2002)
for more customers’ needs to
experimentation
satisfy
Nature of
Familiar local/domestic, closed
Distant, international, open,
(Alajoutsijarvi, et.al,
markets
and networked, there is cost
competitive, there is “time to
1999, Sawyer, 2000)
pressure
market” pressure
Ad-Hoc project organizations
Market, product or matrix
(Alajoutsijarvi, et.al,
organizations
1999)
Based on business unit
(Galbrait, 2002;
performance
Sawyer, 2000)
(Galbrait, 2002)
Type of
organizations
Rewards
Based on company performance
Approach to
Power to people with in-depth
Power to people, who develop
personnel
knowledge of customer’s
products
business
Team
Matrix managed, project focused,
Less likely to have
characteristics
people are assigned to multiple
matrix/project structure, more
projects, work together, salary-
likely to be self-managed,
based, grow larger over time and
people are involved in the
tend to disperse, people rely on
entire development cycle,
specifications and/or documents.
more cohesive, motivated,
(Sawyer, 2000)
opportunities for large
financial rewards, people
share a vision of their product.
Marketing & Sales perspective
Dimensions
Service business
Product business
References
Marketing goal
Managing a company’s customer
Managing a company’s
(Alajoutsijarvi, et.al,
portfolio, building long-term
product portfolio, setting and
1999, Hoch et.al,
business relationships, winning
modifying marketing mix
1999; Nies, 2005;
the trust of customers, customer
parameters to achieve optimal
Cook, 2005, Fornell,
loyalty
4P, branding and image
2002)
Foreign market
Focuses on the character and
The choice of product/market,
(Alajoutsijarvi, et.al,
entry
number of business relationships
defining the goals in the target
1999)
developed with other firms in the
market, the choice of entry
57
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Differentiation
foreign network as well as with
mode; Developing a marketing
the actors that are active in the
plan for penetration, creation
development of these
of control systems for
relationships
monitoring
Relationship differentiation
Product differentiation
(Alajoutsijarvi, et.al,
1999)
Market
Interactive communication,
One-way communication,
(Alajoutsijarvi, et.al,
interaction
mutual learning and adaptations,
formal market studies, seller is
1999)
all interaction parties are active.
the active counterpart.
Crucial
Not seen as important
Negotiations
(Alajoutsijarvi, et.al,
1999)
Identification of
Before development begins
After development ends and
(Keil & Carmel, 1995),
the product goes to market
(Grudin, 1991)
Broad, faceless end
(Alajoutsijarvi, et.al,
customers
1999)
Usually one
Many
(Keil & Carmel, 1995)
On the side of buyer in the
On the side of seller in the
(Galbrait, 2002)
transaction
transaction
Returns to
A variable cost structure makes
A fixed cost structure allows
Scale
increased returns from scale rare
for higher returns from scale
most customers
Customer base
Number of
Narrow, well-known customers
customers
Sales bias
(Nabisan, 2001)
Company (Organizational) perspective
Dimensions
Service business
Product business
References
Business focus
Meeting the customer needs
Research and development
(Cusumano, 2004;
within budget and time,
and market share, profit, mind
Bergström &
contractual fulfillment,
share and providing best
Dahlqvist, 2007,
satisfaction, user acceptance,
product for the customer
Galbrait, 2002,
ROI and providing best solution
Sawyer, 2000, (Keil &
Carmel, 1995, Artz
et.al, 2010)
Business model
Sales of services through
Sales of packaged/modular
(Coloumbe, 2000;
development, maintenance,
software products, large
Hoch et.al, 1999,
support and implementation, high
investment, low marginal
Alajoutsijarvi, et.al,
marginal costs, service content is
costs, service content low
1999, Artz et.al, 2010)
(Galbrait, 2002)
high
Value creation
Customizing for the best total
Cutting-edge products, useful
route
solution, Personalized packages
features, new applications
58
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
of service, support, education,
consulting
Production
Activities within projects,
Duplication, production of
(Alajoutsijarvi, et.al,
production ‘after sales’,
updates or versions,
1999)
connections between all
production before sales,
functions of the company,
production function rather
discontinuity between projects,
independent from other
deadlines are crucial
company functions
Central
Project marketing; client mgmt.;
Productization, channel
(Alajoutsijarvi, et.al,
capability
project management
management, alliance building
1999, Cusumano,
strategic partners in the
2004)
industry, global marketing and
mass customization
Nature of
Interactive, mutual, multi-
Opportunistic, short-term
(Alajoutsijarvi, et.al,
exchange
facetted, long-term oriented,
oriented, product-related
1999)
project related exchange
exchange
Convergent thinking: what
Divergent thinking: how many
combination of products is best
possible uses of this product
for the customer?
are there?
Most profitable, loyal customer
Most advanced customer
(Galbrait, 2002)
Customer relationship mgmt.
New Product Development
(Galbrait, 2002)
Organizational
Customer segments, customer
Product profit center, product
(Galbrait, 2002)
concept
teams, customer P&Ls
reviews, product teams
Measures
Customer share of most valuable
Number of new products,
(Galbrait, 2002, Artz
customers, customer satisfaction,
Market share
et.al, 2010)
Mental process
Most important
(Galbrait, 2002)
customer
Most important
process
lifetime value of a customer,
customer retention
Common types
New system project;
New products; new versions
(Keil & Carmel, 1995,
of projects
“Maintenance” enhancements
(major and minor)
Artz et.al, 2010)
Product lifecycle
Development and then
Delivering product through
(Bergström and
maintenance
incremental releases
Dahlqvist, 2007, Artz
et.al, 2010)
Delivery
Delivering software professionals
Global marketing and mass
(Koenig, 2005;
(developers, testers, consultants)
customization
Cusumano, 2004)
to specific markets
59
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Valuing
After the project is implemented
Before the purchase of the
and delivered to the customer
product
Abstracting
Knowing client’s idiosyncrasies is
The company must be able to
knowledge
more important than knowledge
gather generic product
abstraction
knowledge so that the product
(Hoch et.al, 1999)
(Nabisan, 2001)
can be used in a variety of
contexts
Product
Less important
Very important
(Nabisan, 2001)
complementarity
Development perspective
Dimensions
Service business
Product business
References
Development
Software developed for internal
Software developed for
(Keil & Carmel, 1995,
goal
use (usually not for sale)
external use (i.e. sale)
Artz et.al, 2010)
Development
Process is more mature, there is
Process is immature, there is
(Sawyer, 2000, Artz
process
separated design and
somewhat integrated design
et.al, 2010)
development, design control is
and development, design
done via consensus building
control is done via
coordination
Requirements
Elicited from one customer
Elicited from the market
elicitation
(Bergström and
Dahlqvist, 2007, Artz
et.al, 2010)
Requirements
Contractual document is used
specification
Central database is used for
(Bergström and
large requirements
Dahlqvist, 2007, Artz
et.al, 2010)
User
User is close and more involved
involvement
Terms for
User, End-user
User is distant and less
(Sawyer, 2000, Artz
involved
et.al, 2010)
Customer
(Keil & Carmel, 1995,
software
Artz et.al, 2010)
consumer
Physical
Usually small (e.g. customers are
Usually large (e.g. customers
(Keil & Carmel, 1995,
distance
in the same building as
are spread worldwide)
Artz et.al, 2010)
between user
developers)
(Nabisan, 2001)
and developer
Connection with
Companies have project-driven
Long term relationships:
users
relationships: typically users are
typically users are
technologically unsophisticated.
technologically sophisticated
Table 7: Summary of the characteristics of both types of software businesses
60
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4.6. Dimensions for productization process
The aim of the literature study was to characterize both the custom software services business
and standard product software business since both types of businesses follow different business
models and development approach from a strategic point of view. The differences have been
identified based on different dimensions such as business models, capabilities, organizational
perspective, development perspective, work culture and team, etc. (See further table 7 for more
dimensions).
Artz et.al (2010) had already created the criteria table for each stage in the productization
process to describe each stage based on different dimensions. In this thesis project, the criteria
have been improved with additional dimensions with the aim to give firstly a complete overview of
transformation from service business to product business. The descriptions per stage have also
been changed to make them understandable with the aim to test the applicability of the process in
a service business. Based on the literature study results, there are three more dimensions added
to the criteria table. These are marketing goals, which play a crucial role when transforming. This
dimension includes steps which a service organization needs to take to achieve large markets
after having productized the offerings/service, development teams: this is related to the fact that
the development teams’ mindset changes toward product development and get involved in the
entire development lifecycle of the product (see table 8 below).
As stated earlier, the first three stages of productization process are related to custom software
development. The third stage on the process concerns the decision moment, to see whether a
service company wants to develop a recognized product further and deliver it to a market. The
fourth stage can be characterized as hybrid business, where an organization follows both custom
and product software development approach since customer satisfaction continues to be an
important aspect during the whole productization process. Fifth stage is again the decision
moment to see whether an organization will offer standard software with a certain degree of
customization for its customers or develop standard product software with no customization at all.
From the fifth stage on, the process describes the stages, which characterize only the standard
product development.
As it can be seen in Appendix A – Dimensions, the required steps for each dimension in the
process enable service businesses to go from one stage to another in the process when
transforming. In this sense, the further a service company transforms through the productization
stages, the more it will follow a product-oriented approach. The following dimensions are applied
for transforming from customer specific software development to standard product software
development shown in table 8:
61
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Dimensions
Customized software
Standard software
Software
Customized software project
Standard software product
Business focus
Meeting the customer needs
Gaining market share
within budget and time,
contractual fulfillment
Requirements gathering
Gathered from one customer
Gathered from whole market
Requirements selection
Select requirements per project
Optical selected subset of
(More or less fixed list of
requirements
requirements)
Marketing goals
Interaction, relationship and
Product, price, place and
networks
promotion (4P’s), branding and
differentiation
Sequel
One release, then maintenance
Several releases based on
market requirements
Development teams
Project focused, people are
Product-focused, self-managed,
assigned to multiple projects
Involved in the entire
development cycle
Stakeholder involvement
High external, barely internal
High internal, low external
Table 8: Dimensions for productization process (expanded from Artz et.al, 2010)
62
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4.7. Software Product Management
In this chapter we will shed more light on software product management since it is an important
and relevant subject for this thesis project to gain insight in all the focus areas of SPM for an
efficient product management. Ebert (2009) defines SPM as “ the discipline and business process
governing a product from its inception to the market or customer delivery and service in order to
generate the largest possible value to a business. Product management provides leadership to
activities such as portfolio management, strategy definition, product marketing and product
development”.
Van de Weerd et.al (2009) have developed a reference framework for SPM to get an
understanding of software product domain. The framework includes the focus areas ‘portfolio
management’, ‘Product road mapping’, ‘Release planning’ and ‘Requirements management’. The
focus areas are shown in the framework as follows:
External
stakeholders
Software Product Management
Internal
stakeholders
Portfolio management
Market analysis
Product lifecycle
management
Partnering &
contracting
Company board
Sales
Product planning
Market
Roadmap
intelligence
Product
roadmapping
Core asset
roadmapping
Requirements
prioritization
Scope change
management
Build validation
Release definition
Release definition
validation
Launch
preparation
Release planning
Marketing
Research &
innovation
Customers
Partners
Development
Support
Requirements management
Requirements
gathering
Requirements
identification
Requirements
organizing
Services
Figure 14: Reference framework for SPM (Van de Weerd et.al, 2009)
Each focus area consists of certain business functions (White boxes in figure), which represent a
group of capabilities. The arrows between the capabilities show the interactions between them.
Each capability is defined as a goal that must be achieved to increase the maturity level of a
company’s product (Bekkers and Weerd, 2010).
63
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
a) Portfolio management
Portfolio management concerns the decision-making about the set of existing products,
introducing new products by looking at market trends and the product development
strategy, making decision about product lifecycle, and establishing partnerships and
contracts (van de Weerd et.al, 2006). When we look at the reference framework, this
focus area consists of the business functions: Market analysis, product lifecycle
management and Partnering and Contracting. Input is captured from the company
board, market and partner companies for this process area.
b) Product planning
This focus area concerns the business-oriented long-term planning and technology
forecasting. Forecasting concerns technology or market trends; and planning concerns
product, product-lines, resources or the entire company (Kappel, 2001). This focus area
consists of the business functions: Roadmap intelligence, Product road mapping and
Core asset road mapping. Regnel and Brinkkemper (2005) describes road mapping as “
a document that provides a layout of the product releases to come over a timeframe of
three to five years”. Roadmap is created in terms of expectations, plans, themes and
core assets of the product (Moon and Yeom, 2004). The input for road mapping is
captured from portfolio management. The captured input is used to identify themes and
core assets. Themes are meant to give a clear direction to the roadmap and later to
structure the requirements. Core assets are the components that are shared by multiple
products.
c) Release planning
Release planning is “the process through which software is made available to, and obtained by its
users“ (Van der Hoek, 1997). Based on the reference framework, this focus area consists of the
business functions: Requirements prioritization, Scope change management, Build validation,
Release definition, Release build validation and launch preparation. The starting point for a
release planning is prioritizing the product requirements. Different stakeholders such as
customers, partners and internal stakeholders can prioritize the requirements. After prioritization,
the next step is selecting those prioritized requirements, which will be implemented in the next
release. When selecting the requirements, estimation is also performed, which means that all the
necessary resources (development effort, hardware, software, testing) to implement the
requirements are taken into account. After having selected the to be implemented requirements,
a release definition document is written, which will be approved by different stakeholders. Also a
64
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
business case document is sent to the company board. After the board approves the business
case, launch preparation package will be created and sent to all the stakeholders.
d) Requirements management
Requirements management is a key focus area in software product management. This
area
includes
the
business functions:
Requirements gathering,
Requirements
identification and Requirements organizing. The starting point for requirements
management on the reference framework starts by gathering all the requirements
coming in from within the company and external stakeholders. The incoming
requirements are gathered and organized into product requirements. The difference
between requirements and product requirements lies in the fact that requirements refer
to all incoming wishes and change requests. In this sense, these not only concern the
market requirements but also service requirements, board requests, technological
drivers from research and innovation. Requirements are identified and rewritten to
product Requirements and those that describe similar functionality are grouped together
by linking market requirements and product requirements to each other.
4.7.1. SPM maturity matrix
Maturity matrix is a key component of the Situational Assessment Method for software product
management. This matrix is structured based on the SPM reference framework in Figure 14 and
presents all the relevant capabilities that help organizations improve their software product
management practices.
Maturity matrix consists of columns and rows, which represent the two dimensions of the model.
The columns from 0 to 12 represent the maturity levels, where 0 is the lowest and 12 the highest.
Software product management focus areas are placed in the rows and divided into four groups,
mainly: Requirements management, Release planning, Product road mapping, Portfolio
management.
When a process is carried out at a certain maturity level, it is called ‘capability’. In table 1, we can
for example look at the capability “Requirements identification A” in the left row, which is on the
maturity level one. On the maturity capability matrix, this capability is described as “Market
requirements are rewritten to product requirements using a pre-defined template if the market
requirement is applicable to a product”. The matrix is shown as follows in table 9:
65
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Maturity
Process
0
1
2
3
4
B
C
5
6
7
8
D
E
C
C
F
9
10
Requirements management
Requirements gathering
Requirements identification
Requirements organizing
A
A
B
B
A
D
Release planning
Requirements prioritization
Release definition
Release definition validation
Scope change management
Build validation
Launch preparation
A
A
B
B
C
A
A
C
D
D
B
C
B
B
A
A
E
E
C
D
C
B
C
D
E
A
B
C
B
C
D
C
F
Product planning
Roadmap intelligence
Core asset road mapping
Product road mapping
A
A
B
D
E
D
E
Portfolio management
Market analysis
Partnering & contracting
Product lifecycle management
A
A
A
B
B
B
C
D
C
C
D
D
E
E
E
Table 9: SPM Maturity matrix (Weerd, et.al, 2009)
4.7.2. Situational Assessment Method
As stated earlier, in software product management several business functions related to software
development are managed, among which are requirements management, release planning,
product planning and portfolio management. The quality of the end product is influenced by the
management approach of these functions. Improved software product management (SPM)
processes increase the overall quality of a software product. To aid the product manager in
increasing quality in these processes, the situational assessment method (SAM) for software
product management can be performed. This method assesses the current SPM maturity level,
identifies areas that can be improved and provides guidelines on how to improve them.
The Situational Assessment Method (SAM) includes four processes. The first process is the
Questionnaire. At this step, an interview is conducted with the different stakeholders of a
company to assess the product management processes. The interview consists of two sets of
questions with highly structured answers. The first set of questions complete the Situational
Factor list. The second set is answered by yes/no and forms the Input Capabilities. The
questionnaire on situational factors collects information about the Situational Factor values of the
corresponding organization while the questionnaire on the implemented Capabilities determines
which capabilities are implemented within the organization. The second process is called
66
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Calculation and based on the input from the questionnaires a maturity matrix and capability matrix
are constructed.
These matrices show the capability and maturity profile of the interviewed
company. Furthermore, areas of improvement are determined in this step. In the third process,
Selection, suitable process fragments are selected to improve processes, based on the
determined areas of improvement. During the last process, Feedback, advice is given and
evaluated. The composed method is used to improve the SAM knowledge base.
The SAM process is shown as follows:
Figure 15: Situational Assessment Method (Bekkers, Spruit, Weerd and Brinkkemper, 2010)
67
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
5. Interview results
In this thesis project, we interviewed with 10 interviewees from different functions and domains
and 7 potential products/projects have been identified for the evaluation and validation of
productization process. The primary source for the identification of relevant interview candidates
was the professional environment of the researcher performing the research study. The
environment concerns the Working Tomorrow (WT) Program of Logica, which aims to research
the feasibility and opportunities of the innovative technologies on the area of ICT and in this
sense, provides the graduates the chance to perform their (research) thesis, which can create a
value proposition to the organization. The environment includes the mentors and professionals
from different expert fields, who guide the researchers in executing their research thesis. Table 1
describes the final set of interviewees. At the initial stage of the research, the goal was to identify
as many interviewees as possible to validate productization process thoroughly, there are in this
sense 20 potential candidates identified to interview but in the end, 10 interviews were completed
considering the increasing scope of the thesis project, which can also be justified by Guba (1978).
The following table shows the demographics of the identified interviewees:
Interviewee
Years of experience
Current profile
in service business
1
23
Delivery manager projects: responsible for projects to deliver
on time and within budget that meets client expectations.
2
17
Product manager; responsible for managing the products that
fit the market needs, identify the needs and communicates to
internal and external stakeholders.
3
12
Experienced project manager, service manager, and test
manager in national and international environments, mainly in
Telecom or Telecom related markets.
4
14,5
Program manager, project manager, responsible for devising,
organizing and implementing projects that are complex in
nature.
5
25
Delivery manager central government, infrastructure and
environment.
6
12
Project manager with substantial experience in managing
diverse ICT projects such as Data migration, infrastructural
software development and COTS implementations.
7
20
Software Architect/Product manager
8
7
Software Architect
68
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
9
8
Sales & Solution manager for several clients within utility and
Telecoms sector
10
5
Project manager at Technical Software Engineering
Table 2: Interviewee demographics
During the interviews with the identified interviewees, seven products have been identified, where
the productization process could be applied. It has been taken into account that these products
had the potentials to be developed further as standard product software and they are identified
from different market sectors with the aim to execute the research as robust as possible. The
reason why we considered only seven products have to do with the planned timeframe of the
thesis project and taking more products to assess on the process would risk the thesis project to
finish
on
the
given
timeframe.
6. Productization approach
This section presents the productization approach, which is developed by Artz et.al (2010). This
approach is used when a company is willing to transform into a product software company. We
will apply the approach on the identified products at Logica, which is a company that provides
business and technology services. Worldwide it has 39.000 employees and the company offers
business services, system integration and outsourcing for customers all over the world. Some of
Logica’s clients are the largest companies in Europe.
The reason why the research is performed at Logica is related to the fact that Logica as a service
business does currently efforts to set up product management processes in place since there are
69
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
potential products developed from the custom projects across the business units in the whole
organization. In this sense, the productization process is for Logica an interesting research
subject to assess how mature the company is on their way to become product-oriented.
Assessing the productization process at a service business as Logica will give us insight in the
current strong and weak areas of other service businesses from a product management
perspective.
The productization approach consists of the following steps:

Determination of the initial position: The initial position of each project is determined
through the SPM maturity matrix assessment and the selected stages within the
productization process. SPM maturity assessment consists of the situational factor
questions and the questions related to the determination of the maturity level of SPM
processes. The stages within the productization process are selected per identified
dimension to determine the initial position of a project.

Gap analysis: The gap analysis identifies the distance from the initial position until being
fully software product business oriented. Situational factors by Bekkers, et.al (2008a) are
used to determine the best suitable maturity levels for each project based on the product
management functions. The aim is to determine which processes need to be
implemented or improved based on the initial maturity level of each project.
In this thesis document, we present only two business cases, where the approach is applied. We
consider hereby the increasing size of the documents. The analysis of other cases is presented in
the other corresponding deliverables.
6.1. Initial position
As stated earlier, the initial position is determined by carrying out the SPM maturity assessment
and the selected stages per each dimension within the productization process. These approaches
will be elaborated further in this section.
6.1.1. SPM maturity assessment
We assessed the maturity of each project from the software product management perspective by
using maturity assessment tool developed by Weerd et.al, (2009). This tool gave us insights in
the implemented and missing SPM areas to become software product oriented business. The
assessment consisted of the situational factor questions, maturity questions and maturity matrix.
Additionally, the productization process has been filled in by the relevant stakeholder(s) to
determine the initial position of each project based on certain dimensions.
70
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Situational factors
The situational factors describe the current environment of the projects. Different questions are
asked to the stakeholders based on the different characteristics of those projects such as:
Business unit characteristics, customer characteristics, product/project characteristics and
stakeholder involvement. Artz et.al (2010) state that the identification of situational factors gives
the influence weight of each factor on the SPM processes so that it is possible to determine which
level of maturity suits the best.
Maturity questions
Maturity questions are related to different product management focus areas and each focus area
has certain number of capabilities, which are indicated by letters from A to F. Each capability
represents one particular aspect that needs to be considered in an efficient product management.
Based on the maturity questions, a maturity matrix is generated (see table 9), which consists of
the product management focus areas on the left side and the maturity levels from 0-12 on the
right side. Maturity level indicates to what extent a certain process is implemented. We identify
three different maturity levels: The overall maturity level, which is calculated based on all the SPM
implemented and missing processes of the project, Focus area maturity level, which is calculated
based on the implemented and missing capabilities in a particular focus area and maturity level
per specific process, which is calculated based on the implemented and missing capabilities for a
particular process. The lowest maturity score shows the actual maturity for each of these levels.
Dimensions for productization
The dimensions have been already identified by Artz et.al (2010) to determine the initial position
of a project in the productization process. These dimensions have been identified based on the
differences between service business and product business. During this thesis project, the
existing dimensions have been improved and more additional dimensions have been added
based on the performed literature study (see section 5.5). The dimensions, which characterize
different stages, are ‘Software’, ‘Business focus’, ‘Market goals’, ‘Lifecycle’, ‘Software
development philosophy’, ‘Requirements gathering’, ‘Requirements selection’, ‘Development
teams’ mindset’, ‘Stakeholder involvement’. This part is used to determine the initial position. The
intention is that the stakeholders will select the applicable stages for the corresponding project
based on the identified dimensions. According to Artz et.al (2010), determining the initial stage is
71
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
the start point of the transformation and it continues until 6a or 6b is reached and all the SPM
processes are properly implemented.
6.2. Gap analysis
The gap analysis is used to identify the distance from the initial position to the most suitable
position in the productization process. According to Artz et.al (2010), the first step for the gap
analysis is to determine at which maturity level the projects are based on the implemented
software product management processes. This is performed with the situational questions of
each project.
6.2.1. Situational factors
The situational factors are used to calculate the best suitable stage for the projects. In this sense,
Artz et.al, (2010) consulted the research paper of Bekkers et.al (2008), who identified the most
important situational factors to improve the software product management processes. Based on
the results from Bekkers et.al (2008), the following situational factors, which have the highest
influence on the four SPM focus areas, are used:
Factor
Influenced SPM focus area(s)
Product lifetime
Portfolio management
Value ranges (Bekkers et.al, 2008c)
Range from 1 to 15
Product road mapping
Market size
Portfolio management
0-500 (8x), 500-1500 (1x), 1500-3500
(1x), 3500+ (3x) one outlier
Customer satisfaction
Product road mapping
Range from 6 to 8
Legislation
Release planning
Strict (7x), Loose (7x), Non-existing (0x)
Release frequency
Release planning
Range from 7 to 170 days, and outlier:
365 days
New requirements rate
Requirements management
Range from 2 to 500, and one outlier:
1500
Customer involvement
Requirements management
Low (1x), Medium (6x), High (6x), and
one combination (M/H).
Table 10: The chosen most important situational factors from (Artz et.al, 2010)
6.2.2. Maturity matrix
The maturity matrix has also been used to determine the best suitable product management
processes of each project. Based on the matrix, the implemented and missing processes have
been identified per project. Per SPM focus area, the best suitable maturity level is determined
based on the situational factor of each project. Finally, all the missing processes per project have
been grouped as short-term and long term processes to implement.
72
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
6.3. Recommendations
After determining the initial position and performing the gap analysis for each project, some
recommendations will be given to Logica on becoming product oriented. For each analyzed
project, specific processes will be identified, which can be implemented in the short term to
become market-oriented. In this thesis, we don’t include the processes in the long term
considering the scope and size of this document. The processes in the long-term have been
presented to the stakeholders for each project in a separated report.
9. SPM maturity measurements
In this section, we will present the calculations (see Appendix C – SPM Capability calculations)
that we have made based on the overall results per analyzed product. The purpose behind this
calculation is showing how many capabilities have been implemented per product and what the
overall percentage is of an implemented capability based on the analyzed projects/products. We
will reflect these calculations firstly per focus area including all the relevant capabilities and then
we will present the overall results of all the capabilities in all the focus areas of software product
management.
73
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
During this thesis project, we have assessed seven products at Logica from the software product
management perspective to identify the maturity of the product management processes. Based
on the results, we categorized the products into advanced products and emerging products. Only
two of the seven products were mature in their SPM processes and followed a market-oriented
approach for the development. The other five were still immature to become fully market-oriented
products despite the fact that they implemented some SPM processes quite well.
The overall results per focus area are shown in table 17 for both advanced and emerging
products:
Focus area
Advanced (2)
Emerging (5)
Total (%)
Portfolio management
21,9
14,2
36,1
Product road mapping
19,3
15,3
34,6
Release planning
24,7
45,6
70,3
22
41,7
63,7
Requirements management
Table 17: Percentage of implemented capabilities per focus area
In addition, we will also look at the divergent patterns on SPM capability implementation, which
means that a certain capability has been implemented either by only one or two products or has
not been implemented at all or has been implemented by all the products per process area.
These divergent patterns exist since each product has its own specific situation based on the
software product management maturity assessment.
9.1. Portfolio management
Portfolio management is one of the focus areas, where the analyzed products score very low (see
appendix D – Portfolio management). In the overall results, only 36,1 % of the capabilities has
been implemented for the portfolio management. When we look at the processes, 31,4 % for the
market analysis, 51,4 % for the partnering and contracting and 25,7 % for the product lifecycle
management.
There is for example a divergent pattern in the market analysis process area. We see that none
of the product teams have implemented ‘custom market trend identification’ (Market analysis –
Capability E), where external market research parties are used to perform a market analysis for
the products. This capability causes a divergent pattern. The first argumentation hereby is that
74
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
most of the products still follow the project focus, where the development occurs based on the
customer needs instead of market needs. In this sense, we can state that the relevant knowledge
is missing on how to perform the market analysis. Another reason goes for the products that
follow market-orientation. The teams that manage these products prefer simply to perform the
market analysis by themselves.
In the partnering and contracting process area, we can also see that capability E is implemented
only by one product. This capability concerns having ‘monitored partner network’. The reason
why this capability has not been implemented lies in the fact that the teams of the concerning
products do not involve partners content wise in the development and management of the
products. The partners play only an important role by delivering the relevant components for the
products.
For the product lifecycle management, there are two capabilities, which have not been
implemented at all and these cause the divergent pattern. The capabilities are ‘Product scope
analysis (Capability C)’ and ‘ Product lines (Capability E)’. Product scope analysis balances the
products in the portfolio and identifies opportunities for reuse and discover possible new market
segments. Product lines are developed to enable reuse of resources and simplify the creation of
new products. First of all, the main reason of not implementing these capabilities lies in the fact
that there were no other products in the product line for the analyzed products since the products
are developed either on contractual agreement at the customer side or it is a European
procurement from the local government. Secondly, the stakeholders indicated during the
interviews that these capabilities are not relevant for the analyzed products since these
capabilities must be implemented firstly in the whole organization, which means that there should
be a structured product portfolio management, where the awareness of these products needs to
be created. In the current situation, the analyzed products have all the potential to become
market-oriented products but organization wide; there is no awareness and indirectly no support
to develop them further for the potential markets or market segments.
9.2. Product planning
When looking at the overall results on product road mapping, the maturity of the products in this
area is also on a low level. The average percentage of the implemented capabilities is 34,6 %.
The percentages for the process areas are; Roadmap intelligence: 25,7 %, Core asset road
mapping: 53,5 % and product road mapping: 25,7 %.
Divergent patterns exist in this focus area too, especially roadmap intelligence and product road
mapping process areas. Roadmap intelligence gathers decision-supporting information needed in
75
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
the creation of product roadmaps. The roadmap intelligence on partners and competitors are not
being performed except that one product did implement it. The reason is that the most of the
teams of the corresponding products are not mature enough yet with their mindset to gather
information on the market needs. Most of the teams are reactive to the changes and listen more
to the customer needs. Some indicate that they are not concerned to gather information on the
competitors because of the stability of the market, where they are operating on.
In the product road mapping area, one of the capabilities concerns creating external variants of
the product roadmap (Capability E). The main reason of not implementing this capability is related
to the fact that market orientation is missing at most of the products and product road mapping is
not implemented at all. Despite the fact that external roadmaps are useful for the product lifecycle
management, the teams indicated that creating roadmap is not relevant for the current stage of
the product unless there is already an investment or support coming from the company board.
One particular product team has implemented this capability since they were aware of the
commercial side of the product based on the market needs. It is remarkable to state that most of
the teams aren’t concerned with the partners’ developments or involving them in the decisionmaking for the product development. In this sense, the roadmap to the partners was also not
relevant for the most of the teams.
9.3. Release management
Release planning is one of the focus areas, where most of the capabilities have been
implemented. For the most of the products, release planning is a known focus area and teams
follow a structured approach to perform it however release planning is mostly performed from the
customers’ perspective. When we look at the average score of the implemented capabilities, 70,3
% of the capabilities related to release planning has been implemented. Specifically, 77,1 % of
the capabilities has been implemented in requirements prioritization, 74,2 % in release definition,
61,9 in release definition validation, 82 % in scope change management and 61,9 on release
build validation and release launch preparation.
As stated earlier, release planning focus area is quite mature based on the analyzed products.
However when we look for example at the requirements prioritization, we see that there is a
divergent pattern present. All of the teams have implemented for example the capability D, which
concerns the cost revenue consideration for the requirements during the prioritization. This is a
quite important capability to have in place since the related costs are always taken into account
before implementing them. In this sense, it does not matter whether it is a project or market focus.
Another capability concerns the partner involvement (Capability E). Only one product team has
implemented this capability but in general, most of the product teams don’t involve partners in the
76
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
requirements prioritization process. This is again related to the project focus, where the
customers’ needs and wishes are the main drivers to consider and the partners are the suppliers
of the necessary components.
Another divergent pattern is on the release build validation. All of the product teams indicate that
internal and external (mostly customers) stakeholders validate the release however there is not
an external (formal) certification obtained by a third party to validate the release. During the
interviews, the interviewees have indicated that they simply don’t need an external certification to
be obtained since most of the products have been developed based on the customer needs and
the validation from the customer is sufficient for the release. For one particular product team, it
was necessary to obtain a formal (external) certification since the product contains critical user
information and all the data processing needs to occur safely, which means that the product
should meet the criteria of all the legal forms.
9.4. Requirements management
Based on the maturity assessment results, 63,7 % of the capabilities related to requirements
management have been implemented, which is on a reasonable level, nevertheless there are still
some improvements that need to be made for the requirements management from a marketdriven perspective. When we look specifically at the average percentage of the implemented
capabilities
per
process
area;
Requirements
gathering
scores:
61,9%,
Requirements
identification: 50 % and requirements organizing is 85,7 %.
The divergent patterns exist in the requirements gathering and requirements identification
process areas. All of the product teams have indicated that the incoming requirements are
gathered and registered and that these requirements are also stored in a central database for
most of the requirements but 6 out of 7 product teams indicated that there is not any automated
process to store requirements. This lies in the fact that most of the products are in the stage of
maintenance at the customer side and the total number of incoming requirements was not on a
large scale. The latter made the use of an automated process unnecessary. Another capability is
gathering of requirements from the partners. Except one particular product, none of the teams
gathered the requirements from the partners since some of them either do not collaborate with
partners or they collaborate with partners based on the delivered components.
Another divergent pattern is the identification of requirements, which concern the capabilities
related to connecting similar requirements with each other (Capability C). Some of the product
teams indicated that they encounter almost no similarities between the incoming requirements
and that they do not see the necessity to implement this capability based on the number of
77
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
incoming requirements and another factor is related to using linguistic engineering tool to connect
the similar requirements with each other (Capability D). During the interviews, most of the product
teams were not aware of this tool for handling the requirements and did not know how to use it.
9.5. Conclusion
In this section, we presented the average score of all implemented capabilities based on the four
software product management focus areas. The results indicate that we deal with divergent
patterns based on the implemented SPM capabilities per each focus area. This has to do with the
fact that each product has its own specific situation in the sense that they are either quite mature
in some of the SPM processes or quite immature. This is on the one hand understandable since
the products are developed in an IT service business, where there is knowledge or mindset
missing to have those missing SPM processes in place, especially when it comes to marketing
and all the related external factors.
As it can be seen in the calculations in appendix D, most of the missing capabilities are in the
area of product road mapping and portfolio management. Based on the seven analyzed products,
we could clearly identify two products that followed market-oriented approach for the product
development and the other products were quite mature in their internal development of product
from the requirement and release management perspective but they don’t consider the external
factors from the roadmap and portfolio management since they simply miss the knowledge and
experience in this area. The most important one has to do with the investment and support from
the company board for a continuous product development based on the market needs.
Based on the calculated capabilities, the following summarized commonalities are identified per
advanced and emerging product.
78
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Advanced
Emerging
Market orientation mindset
Service business mindset
Active market analysis
No or limited market analysis
Investment and support in the product
No awareness of product(s) in the organization
Considering ecosystems (partner involvement,
Limited partnering (based on components),
make/buy decisions)
high customer involvement in the product
Product lifecycle is present
No product lifecycle (contractual agreements)
Roadmap is present
Roadmap not possible (dependent on the
investment from the company board)
Core assets are important and systematically
Components are saved for reuse at the other
identified and stored in a central location
customers
Requirements captured from all the internal,
Only customer requirements count
external stakeholders and the whole market
Table 18: Commonalities per advanced and emerging product
10. Multi-dimensional productization profile
During the interviews, the interviewees have indicated the applicable stages for the
corresponding products based on the relevant dimensions from the transformation perspective. In
this section, we will present the (multi-dimensional) productization profile of products based on
the selected dimensions. We call this ‘multi-dimensional’ since the applicable stages are selected
on both extremes (for both service and product business) in the productization process at the
same time. In this sense, we will present two examples and underpin why these both extremes
have been selected for these products.
10.1. Productization profile of products
As stated earlier, the productization process consists of six stages, which describe the
transformation from developing customer specific software to standard product software. In this
sense, there are two main extremes identified. On the one end, we deal with the stages that
describe the ‘service business’ and on the other end; there are stages that describe ‘product
business’. There is also the middle point, where the organization follows a ‘Hybrid business’.
We asked the interviewees to fill in the productization process table the best applicable stages for
the corresponding products based on the identified dimensions. When we look at the results, we
see that in some cases, stages have been selected in both extremes for a few of the products. In
general terms, it is remarkable to state that there are certain aspects that affect the productization
process. One of the aspects is related to the mindset of the employees working at the IT service
79
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
business. When there is a product potential identified based on a customer solution, a team is
formed to develop that solution further as a product for a market but in most of the cases, the
employees do not know how to get along with capturing the requirements from the internal and
external stakeholders since these people are used to deliver services to the customers, where a
fixed list of requirements was provided to develop the solution. In this case, a product manager is
unavoidable to lead the way to develop the solution as market-oriented. Second aspect is related
to the financial support from the company board. In an IT service business, the company does not
want to invest in the product financially; instead the company aims to get the financial support
from its customers (unless a solution has a big market potential, a break-through product). This
means that instead of developing the product on the internal initiative, the aim is still to implement
it at certain customers and to provide money stream to the product. Third aspect is related to the
collaboration of different departments across the organization. During the productization, it is
important that sales and marketing/communication is also involved in the whole lifecycle of the
product development and there should be awareness of the product to get support and funding
and this is in most of the cases a missing aspect from productization perspective.
11. Situational factor analysis
In this section, we will present the differences and similarities based on the situational factors of
advanced and emerging products. As stated earlier, situational factors describe the current
80
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
environment of each product and are related to certain characteristics such as business unit,
customer, market, product, and stakeholder involvement. Each of the characteristics describes
the current situation of each product based on different factors. We aim to gain insight in the
differences and similarities per advanced and emerging product based on certain relevant
situational factors.
11.6. Conclusion
In this section, we have analyzed the situational factors for both advanced and emerging products
based on the different characteristics. In the overall results, we can state that the given values for
both types of products are based on market and project approach. When we interpret the given
values in general terms, we present only the remarkable differences and similarities between
advanced and emerging products from the productization perspective.
Based on the situational factors for both advanced and emerging products, we see certain
differences. The most remarkable difference is the mindset of both types of products, where one
focuses on the market and other keeps maintaining the products based on the specific customer
needs. Another difference is that development philosophy is agile for the advanced products,
where the internal and external stakeholders are involved for development purposes, whereas
emerging products prefer using waterfall approach during development. We gave our
argumentations on why there is a difference between both types of products for this factor in
Validation section of this thesis. Customer variability is also one of the differences, where
advanced products have standardized their products for each and every customer, whereas
emerging products still focus on specific customer needs and in this sense, the variability gets
higher. We see that localization is for most of the emerging products not applicable since they
operate in the local markets and advanced products consider it by implementing different
languages for example. Another remarkable difference is the product lifetime, which can be
justified with the focus on releases. Advanced products roll out releases based on the market
needs, whereas the emerging products roll out releases per specific customer. The most
remarkable differences and similarities are shown in the following tables:
Differences
Advanced
Emerging
Market-driven development
Service driven development
Agile development
(Usually) waterfall
Customer variability low
Customer variability high
Localization is considered
No localization (focus mostly on local market)
81
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Releases based on market
Releases based on specific customers
Table 26: Differences between advanced and emerging products based on situational factors
Similarities
Business units are small (since most of the products are on
maintenance stage)
The products operate in small markets
Customer loyalty is high/ customer satisfaction is always considered
The type of customers is medium to large
Top management involvement is missing
Customers are the main drivers for product development
Standard dominance is indicated high by most of the products
Legislation is taken into account for most of the products
Requirements rates are low because of the service mindset for most of
the products
Partner involvement is considered on a low level
Table 27: Similarities between advanced and emerging products
82
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
13. Validation, discussion and further research
In this section, we will present the results related to the validation of productization process. As
mentioned earlier, during this thesis project, we have interviewed people from different domains
based on the seven analyzed products. The aim behind the validation was to identify whether the
process describes the stages clearly for the relevant stakeholders based on the transformation
from developing custom software to standard product software and eventually to find out if the
process was applicable for Logica for developing products based on the market needs.
13.1. Validation of productization process
During the interviews, the process has been firstly explained to the interviewees visually and each
stage has been discussed based on the specific case of Logica. When we look at stage 1
(independent projects), we see that this stage is recognized by all of the stakeholders. We realize
that there is a project portfolio present at Logica, which is managed by the OS (Operational
services). From the operational services, the company has set up different delivery centers where
the necessary custom features, knowledge experts or components are delivered to each of the
independent project based on the specific needs with the aim to meet the customer needs as
efficient as possible. The operational services are thus responsible for the delivery and
management of projects from their initial stage to the exploitation or maintenance stage at the
customer side. The second stage (Reuse across projects) has also been recognized by the most
of the stakeholders despite the fact that some indicated that reusability does not occur in a large
scale in the whole organization. During the interviews, some specific examples have been given
based on feature reuse across the different projects. It is indicated that Logica aims to create
reusable assets at the delivery centers with the aim to standardize the processes from the project
management perspective. The stage 3 (product recognition) is recognizable at Logica but some
stakeholders indicated that product potential is not only determined as a result of stage 2 based
on the standard reusable components but product potential can also be recognized based on a
certain implemented solution/project at one specific customer. This is also justified with the
MolView App product, which has been initially implemented at a utility firm. Some stakeholders
approved the switch from stage 2 to stage 3 in the sense that it contributes to an organization to
become more mature in product orientation mindset however reuse across projects is not the
most important factor that leads to stage 3. One stakeholder claimed that product recognition
couldn’t be seen as a stage for productization but it is more a mindset. The stages from the third
stage on were recognized, as the logical way of transforming from service to product business.
Especially the stakeholders of the advanced products could identify the stages based on their
products and could position their products right away on the process however the stakeholders
from the emerging products did not give much input as expected for these stages. Some
83
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
indicated that they had no experience in the areas of product management or they simply missed
the knowledge since the mindset is delivering services and meeting the customer needs.
Some of the stakeholders have indicated that the stage 1 and 2 of the productization process
need to be merged together since most of the steps are performed at the initial stage of a project.
13.2. Validation of dimensions
During the interviews, the identified dimensions have also been shown to the stakeholders and
they were asked whether each dimension was described clearly for each stage in the process
from the transformation perspective. In the overall conclusion, most of the stakeholders could
understand the stages based on the dimensions however there were some points that have been
pointed out for some of the dimensions.
One of the points that stakeholders have indicated was related to the dimension ‘Development
philosophy’. The motivation to place this dimension for productization is based on the SPM
maturity assessment of the products, where we could see that the (emerging) products have
been mostly developed with the waterfall methodology and this is chosen usually since the
customers preferred and wanted to pay a fixed-price for the developed product from its initiation
to the exploitation. In contrary to waterfall development, the SCRUM methodology has been
applied for the advanced products, where user participation was high. During the validation
interviews, it has been indicated that the development philosophy did not matter and was not
really relevant for the productization process. You can principally perform either SCRUM or
Waterfall methodology at any stage of the productization process however the stakeholders
recognized the added value from this dimension in the sense that development methodology
matters based on the type of the market. When a market requires a high degree of user
participation on the development, the organization needs to re-structure itself to the agile type of
development (in case it wants to enter that specific market) and this can be a quite challenging
transformation.
Another point was that the required step(s) in some of the stages should have been performed in
the other stages. Based on the dimension ‘Requirements gathering’, the required step at stage 2
indicates that the requirements are gathered for each customer and these requirements are
matched with reusable components. According to one stakeholder, matching the requirements
with the reusable components can also be performed already at stage 1. It is claimed that when
there is a new project initiated, identification of the existing (reusable) components is one of the
first steps to consider while implementing the incoming requirements. The same goes also for the
dimension ‘Market goals’, where it is indicated that the marketing activities such as focusing on
84
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
4P’s, branding and differentiation at stage 6 (standard product) can also be performed at stage 4
(product basis). Our argumentation hereby is that in case a product reaching certain level of
maturity on a market, the branding and differentiating plays an important role for the sustainability
of the product. The product company needs to adapt or differentiate itself based on the market
conditions from the 4P’s perspective. This step must be performed at stage 6 since the product
basis (stage 4) concerns the preparation of the product for a market-driven approach and the
maturity is still low compared to stage 6.
13.3. Discussion and further research
During the interviews, there have been some discussion points on the productization process.
One of the discussed points was related to the determination of the initial position of the products
since some of the stakeholders pointed out that the stages have not been described on a
S.M.A.R.T. (specific, measurable, achievable, realistic and time-bound) way. In this sense, it
made for them difficult to choose a certain applicable stage for the products. During this thesis
project, we improved the productization process with its relevant (additional) dimensions based
on the literature study by identifying the differences between service and product business. We
would suggest performing more research on the description of the stages in S.M.A.R.T. way by
taking different service and product businesses into account with the aim to compare those
companies with each other and gain insight in each stage of the productization process.
Another point that is discussed is whether the required steps for each stage in the process
included all the aspects that a service company needs to consider to become market-driven. We
tried to cover all the aspects by an extensive literature study and knowledge gained from Logica
as a service business however more research can be performed to capture more additional steps
for each stage.
The productization approach that is developed by Artz et.al (2010) is also dubious to apply in
practice. This lies in the fact that the approach has been developed two years ago based on the
relevant research subjects of that period of time (e.g. the gap analysis for determining the best
suitable stage based on the research of Weerd et.al (2009)). During this thesis project, we could
apply the approach based on the specific situation of the analyzed products by considering the
mentioned situational factors by Artz et.al (2010), maturity assessments and the selected stages
on the productization process, however more case studies can be performed to validate the
approach by taking into account more additional steps that should be considered while
productizing.
85
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Further research on productization can be performed from the services perspective. In an
interview with the portfolio manager at Logica, he indicated that they are also trying to productize
their service offerings to their customers. This means that when there is a new request coming
from a certain customer for the implementation of a solution, a project is initiated at the customer
side but before the project is initiated, all the necessary resources (e.g. people with project
management skills in a specific area, developers or the (re-usable) components) are identified.
With a productized service offering, Logica aims to deliver the solution as fast and efficient as
possible in high quality. It would be interesting to research how to apply the productization
process from the services perspective.
During this thesis project, we identified certain challenges that Logica has when developing
products from a market perspective. The challenges are related to intellectual property since the
most of the products are developed as projects for the specific customers. A deeper research can
shed light on how service companies need to get along with the intellectual property rights while
developing products from customer specific solutions. Also software ecosystems were not
considered too much while transforming (e.g. partner involvement: Service companies consider
partners only for the delivery of components). A deeper research can shed light on what steps
need to be taken from a SECO perspective when productizing.
We also found out that the internal involvement for the development of a product from a market
perspective is not as expected. The top management plays hereby an important role for example.
Most of the products suffer the investment from the organization, which causes the product not to
be developed further. Further research can provide more insights in why top management is not
involved in the product development.
86
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
14. Conclusion
This thesis project concerned the validation of productization process at the IT service business
‘Logica’. The validation has been performed twofold. The first validation was based on the
assessment of (identified) products, which had the potentials to be developed from the marketdriven, in the productization process. Regarding the assessment we took into account the
situational factors and the maturity level of each identified product based on the product
management areas: portfolio management, product road mapping, release planning and
requirements management. We performed the second validation by considering the thoughts of
the identified stakeholders on the productization process. Consequently, based on the results
captured through the assessment and interviews held with the stakeholders, we were able to
answer our main research question:
“To what extent is the productization process applicable in a service-oriented company when
transforming from developing customer-specific software to standard product software?”
We answered this question by assessing the productization process on seven specific products
identified at service-oriented company ‘Logica’. From the productization perspective, we
performed the steps such as analysis of situational factors (Chapter 11), application of
productization approach (Chapter 7-8) and analysis of productization profile of each analyzed
product (Chapter 10). In addition, we calculated the average percentage of the implemented
capabilities (Chapter 9) per SPM focus area based on the maturity assessment results of all the
products with the aim to gain insight in the strong and weak points of each product management
area.
The overall results indicate that Logica as a service business is not mature in developing
products from a market-driven perspective. This is understandable since the core business is
delivering services and meeting the customers’ needs however the company is aware of the fact
that based on their project portfolio, there are certain projects that have the potential to be
developed as standard product software for certain markets. There are efforts made to gain
insight in market-driven product development. Based on our analysis, we could see that Logica
scored high for the requirements and release management despite the fact that the focus hereby
is still on the specific customer needs. Product road mapping and portfolio management areas
are the weak areas that need to be improved. On the way to become market-driven,
productization process is found applicable for Logica to use as a guide since the company aims
to set up a structured product management process in place. It is essential to state that all the
stages in the process have been recognized by most of the stakeholders however it is also
indicated that the process steps through the stages still need to be developed on a S.M.A.R.T.
87
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
way so that concrete measurements can be made to determine the initial and best suitable
position of a product on the way to become market-driven.
Based on the current stage of productization at Logica, we cannot expect from Logica to apply
the process to its full extent since the basis needs to be set up for a product development
approach. We recommend the company to put more focus on the stages three and four, where
standardization is performed with a structured requirement and release management from a
market-driven approach. In this sense, the overall customer focus needs to be decreased and the
internal stakeholders need to be more involved in the product development.
“What are the dimensions in the productization process that are needed to be able to position a
company’s product at a certain stage?”
This question has been answered in chapter 4, where we performed an extensive literature study
on the differences between service and product business since the process stages are related to
both types of businesses. Based on the identified differences, we chose only the ones that were
relevant for the transformation of custom software to standard product software development.
The dimensions that were already identified by Artz et.al (2010) have also been taken into
account and are improved to make the process steps more understandable. The relevant
dimensions from the transformation perspective concern: Software, Business focus, Market
goals, Lifecycle, Software development philosophy, Requirements gathering, Requirements
selection, Development teams and Stakeholder involvement on development.
Are there more, or fewer stages needed to implement in practice?
Productization process has been validated by certain number of stakeholders from the different
domains at Logica (see chapter 13 – validation). In the validation part, it can be seen that
stakeholders have different opinions about the stages from the transformation perspective based
on the content but regarding the stages it has only been indicated that the stages describing the
service business (especially stage 1 and 2) can be merged together since most of the concerning
steps at stage 2 are performed at stage 1 from the reusability perspective. Another aspect that is
indicated is related to stage 3, that it cannot be seen as a stage but as a mindset. Nevertheless,
based on the overall interview results, stakeholders agree that the identified stages for
productization reflect the logical transformation steps from developing customer specific software
to standard product software and there have been no additional stages indicated for the process.
88
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
What are the challenges that companies face when transforming from developing customerspecific software to standard product software?
The answer to this question is given in chapter 12 - Recommendations. Based on the maturity
assessment and selected applicable stages in the productization process for each product, we
could recognize some concrete challenges in applying market-driven product development in a
service-oriented business. These challenges have to do with financial investment from the
company board, the involvement of top management in product development, Consideration of
Software ecosystems (e.g. following the developments on the partner, customer and competitor
side), collaboration across all the product units and creating awareness of the products in the
whole organization and the management of intellectual property rights, etc. The most important
challenge lies in the fact that people working at Logica have service mindset and they miss the
knowledge on how to develop the product based on the market needs. Assigning product
managers to the (potential) products is a must-have aspect for Logica to consider.
Which processes need to be implemented to go from one stage to another in the productization
process?
We answered this question by applying productization approach, where we assessed the
products based on the selected stages, indicated situational factors and SPM maturity matrix. In
chapter 7 and 8, we presented the results of two different business cases, where the specific to
be implemented processes are identified. Firstly, we interpreted the selected stages based on the
dimensions of productization process for each business case and determined the initial position.
In addition, we combined the interpreted results of productization process with the results of SPM
maturity assessment and identified hereby the implemented and missing processes to go from
the initial position to the best suitable position on the productization process.
89
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
15. References
Alajoutsijarvi, K., Tikkanen, H., & Mannermaa, K. (1999). Customer relationships and the small
software ®rm A framework for understanding challenges faced in marketing. Information &
Management , 153-159.
Apostolou, D., & Mentzas, G. (1999). Managing Corporate Knowledge: A Comparative Analysis
of Experiences in Consulting Firms. pp. 129-138.
Artto, C., Wikström, K., Hellström, M., & Kujala, J. (2008). Impact of Services on Project
Business. 497–508.
Artz, P., van de Weerd, I., Brinkkemper, S., & Fieggen, J. (2010). Productization: transforming
from developing customer-specific software to product software. ICSOB , 90-102.
Beamish, P. (1990). The internationalisation process for smaller Ontario firms: a research
agenda. in Rugman, A.M. (Ed.) Research in Global Strategic Management – International
Business Research for the Twenty-First Century: Canada's New Research Agenda , 77-92.
Bekkers, W., Spruit, M., van de Weerd, I., van de Vliet, R., & Mahieu, A. (2010, June 7-9). A
Situational Assessment Method for Software Product Management. 18th European Conference
on Information Systems (ECIS2010) .
Bekkers, W., van de Weerd, I., Brinkkemper, S., & Mahieu, A. (2008). The influence of Situaional
Factors in Software Product Management: An Empirical study. Proceedings of the 2008 Second
International Workshop on Software Product Management , 41-48.
Bekkers, W., van de Weerd, I., Spruit, M., & Brinkkemper, S. (2010). A framework for process
improvement in Software Product Management. Proceedings of the 17th European Conference
on Systems, Software and Services process improvement (EUROSPI).
Bell, J., McNaughton, R., Young, S., & Crick, D. (2003). Toward an Integrative model of Small
Firm Internationalization. Journal of International Entrepreneurship , 339-362.
Benbasat, I., Goldstein, K. D., & Mead, M. (1987). The case research strategy in studies of
information systems. MIS Quarterly , 369-386.
90
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Bergström, J., & Dahlqvist, A. (2007). BESMART - a framework for shifting from BESpoke to
MARkeT-driven requirements engineering. Master thesis, Blekinge Institute of Technology,
TEK/avd. för programvaruteknik, Ronneby.
Boehm, B. (1987). Improving Software Productivity. Computer , 43-58.
Boehm, B. (1991). Software Risk Management. IEEE Software , 8 (1), 426-435.
Boucharas, V., Jansen, S., & Brinkkemper, S. (2009). Formalizing Software Ecosystem Modeling.
IWOCE'09 , 41-50.
Carlshamre, P., Sandahl, K., Lindvall, M., Regnell, B., & Nat och Dag, J. (2001). An industrial
survey of requirements interdependencies in software product release planning. Requirements
Engineering 2001. Proceedings. Fifth IEEE International Symposium , 84-91.
Carmel, E. (1995). Cycle-time in packaged software firms. Journal of Product Innovation
Management , 110-123.
Carmel, E., & Bird, B. (1997). Small is beautiful: a study of packaged software development
teams. High Technology Management Research , 8 (1), 129-148.
Clements, P., & Northrop, M. L. (1999, September 1). A Framework for Software Product Line
Practice.
Opgeroepen
op
Maart
12,
2012,
van
Software
Engineering
Institute:
http://www.sei.cmu.edu/library/abstracts/news-at-sei/backgroundsep99pdf.cfm
Codenie, W., de Hondt, K., Steyaert, P., & Vercammen, A. (1997). From custom applications to
domain-specific frameworks. Magazine Communications of the ACM , 40 (10), 70-77.
Collis, J., & Hussey, R. (2003). Business Research: A Practical Guide for Undergraduate and
Postgraduate Students. Palgrave Macmillan.
Cook, R. (2005). Taking creative risks. In Aspatore, Inside the minds: Building a successful
software business, top CEOs on software product management, growth strategies, sales and
more (pp. 9-24). Aspatore Books.
Cooper, R. (2000). Creating And Launching Superior New Products. In R. Cooper, Product
Leadership (p. 336). Cambridge, MA: Perseus Books.
91
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Crnkovic, I. (2001). Component-based software engineering - New Challenges in Software
Development. Software focus , 127-133.
Cusumano, M. (2004). The Business of Software: What Every Manager, Programmer, and
Entrepreneur Must Know to Thrive and Survive in Good Times and Bad. In M. Cusumano, New
York: The Free Press.
Cusumano, M. (2008). The changing software business: Moving from products to services.
Journal of IEEE Computer Society , 20-27.
Cyprus, S. (2012, April 11). What is bidding? Opgeroepen op June 18, 2012, van WiseGeek:
http://www.wisegeek.com/what-is-bidding.htm.
Darke, P., Shanks, G., & Broadbent, M. (1998). Successfully completing case study research:
Combining rigour, relevance and pragmatism. Information Systems Journal 8 , 273-289.
Doyle, P., & Wong, V. (1998). Marketing and competitive performance: An empirical study.
European Journal of Marketing , 514-535.
Ebert, C. (2009). Software Product Management. Crosstalk , 22 (1), 15-19.
Flamholtz, E. (1995). Managing organizational transitions: implications for corporate and human
resource management. European Management Journal , 13 (1), 39-51.
Fornell, C. (1992). A National Customer Satisfaction Barometer: The Swedish Experience.
Journal of Marketing , 6-21.
Frye, C. (1998). Gauging the industry. Software Magazine , 18 (9), 24-70.
Galbraith, J. (2002). Organizing to Deliver Solutions. Organizational Dynamics , 31 (2), 194-207.
Gann, D., & Salter, A. (1998). Learning and innovation management in project-based, serviceenhanced firms. International Journal of Innovation Management 2 , 431-454.
Gerstner, L. (2002). Who says elephants can't dance: Inside IBM's historic turnaround, New York:
Thorndike Press.
92
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Goodman, P., Ravlin, E., & Argote, L. (1986, April 1). Current thinking about groups: Setting the
stage for new ideas. Opgeroepen op June 13, 2012, van Tepper School of Business:
http://repository.cmu.edu/tepper/816/.
Gorschek, T., & Wohlin, C. (2006). Requirements Abstraction Model. Requirements Engineering ,
11 (1), 79-101.
Grudin, J. (1991, April 1). Interactive Sytems: Bridging the gaps between developers and users.
IEEE , 59-69.
Guba, E. (1978). Toward a methodology of naturalistic inquiry in educational evaluation. CSE
Monograph Series in Evaluation, 8, Graduate School of Education, University of California, Los
Angeles.
Guilon, L. A., Diehl, D. C., & Mcdonald, D. (2011, August 11). Triangulation: Establishing the
Validity of Qualitative Studies. Opgeroepen op November 2, 2011, van University of Florida IFAS
Extension: http://edis.ifas.ufl.edu/pdffiles/FY/FY39400.pdf.
Harrel, C., & Bradley, A. (2009). Data collection methods: Semi structured interviews and focus
groups. National Defense Research Institute. Santa Monica: RAND Corporation.
Hart, C. (1998). Doing a Literature Review: Releasing the Social Science Research Imagination.
London: Sage Publication.
Heitlager, I., Jansen, S., Helms, R., & Brinkkemper, S. (2006). Understanding the dynamics of
product software development using the concept of coevolution. Second International IEEE
Workshop (SE'06) , 16-22.
Hietala, J., Kontio, J., Jokinen, J., & Pyysiainen, J. (2004). Challenges of software product
companies: Results of a national survey in Finland. Proceedings of the 10th IEEE International
Symposium on Software Metrics , 232-243.
Higgins, S., de Laat, M., Gieles, P., & Geurts, E. (2003). Managing Requirements for Medical IT
Products. Requirements Engineering , 341-349.
Hoch, J. D., Roeding, R. C., Purkert, G., & Lindner, K. S. (1999). Secrets of software success.
Boston: Harvard Business School Press.
93
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Hogan, J., Hogan, R., & Busch, C. (1984). How to measure service orientation. Journal of Applied
Psychology , 69 (1), 167-173.
Hsiu-Lang, C., & Guo, R.-J. (2005). On Corporate Divestiture. Review of Quantitive Finance and
Accounting , 399-421.
Humphrey, W. (1989). Managing the Software Process. Boston: Addison-Wesley.
Jansen, S., Ballintijn, G., Brinkkemper, S., & van Nieuwland, A. (2006). Integrated development
and maintenance for the release, delivery, deployment, and customization of product software: a
case study in mass-market ERP software. Journal of Software Maintenance and Evolution:
Research and Practice , 133-151.
Jones, T., & Sasser, W. (1995). Why satisfied consumers defect. Harvard Business Review , 73
(6), 88-99.
Kang, K., Jaejoon, L., & Donohoe, P. (2002). Feature-oriented product line engineering. IEEE
Software , 19 (4), 58-65.
Kaufman, J., Luciano, C., & Humphries, E. (2002). Market orientation and alternative strategic
orientations: A longitudinal assessment of performance implications. Journal of Marketing , 25-39.
Keil, M., & Carmel, E. (1995). Customer-Developer Links in Software Development.
Communications of the ACM , 38 (5), 33-44.
Kitchenham, B. (2004). Procedures for Performing Systematic Reviews. Software Engineering
Group, Department of Computer Science. Keele: Keele University.
Klopper, R., Lubbe, S., & Rugbeer, H. (2007). The matrix method of literature review. Alternation ,
14 (1), 262-276.
Koeing, H. (2005). Fundamentals of the software business. Inside the minds: Building a
successful software business, top CEOs on software product management, growth strategies,
sales and more. In Aspatore, Building a Successful Software Business (pp. 113-119).
Kought, B., & Singh, H. (1988). The effect of national culture on the choice of entry mode. Journal
of International Business Studies 8 (Fall) , 411-432.
94
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Lassila, A. (2006). Taking a service-oriented perspective on software business: How to move
from product business to online service business. IADIS International Journal , 4 (1), 70-82.
Lehman, M. (2001). Rules and Tools for Software Evolution Planning and Management. Annals
of Software Engineering , 11 (1), 15-44.
Lehman, M., & Ramil, J. (2001). An approach to a theory of software evolution. Proceeding
IWPSE '01 Proceedings of the 4th International Workshop on Principles of Software Evolution ,
70-74.
Leonard-Barton, D. (1992). Core capabilities and core rigidities: A paradox in product
development. Strategic Management Journal , 13, 111-127.
Lynn, M., Lytle, R., & Bobek, S. (2000). Service orientation in transitional markets: Does it
matter? European Journal of Marketing , 279-298.
Lytle, R., Hom, P., & Mokwa, M. (1998). SERV OR: A managerial measure of organizational
service-orientation. Journal of Retailing , 74 (4), 455-489.
MacCormack, A. (2001). Product Development Practices that Work: How Internet Companies
Build Software. MIT Sloan Management Review 42 , 75-84.
Macmanus, R. (2009, August 11). Gartner Hype Cycle 2009: Web 2.0 Trending Up, Twitter
Down. Opgeroepen op March 30, 2012, van ReadWriteWeb:
http://www.readwriteweb.com/archives/gartner_hype_cycle_2009.php
McConnel, S. (1998). Software Project Survival Guide: How to Be Sure Your First Important
Project Isn't Your Last. Redmond: Microsoft Press.
Mehrmann, J. (2007, September 10). What is Matrix Management? Opgeroepen op June 11,
2012, van Executive Blueprints:
http://www.executiveblueprints.com/tips/070826matrixmanagement.htm
Messerschmitt, D., & Szyperski, C. (2003). Software Ecosystem: Understanding an Indispensable
Technology and Industry. California: MIT Press.
95
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Moen, Ø., Gavlen, M., & Endresen, I. (2004). Internationalization of small computer software
firms, Entry forms and market selection. European Journal of Marketing , 1236-1251.
Mosakowski, E. (1993). A Resource-Based Perspective on the Dynamic Strategy-Performance
Relationship: An Empirical Examination of the Focus and Differentiation Strategies in
Entrepreneurial Firms. Journal of Management , 819-839.
Nambisan, S. (2001). Why service businesses are not product businesses. MIT Sloan
Management Review , 42 (4), 72-80.
Niels, T. (2005). Client success powers our success. In Aspatore, Inside the minds: Building a
successful software business, top CEOs on software product management, growth strategies,
sales and more (pp. 33-57).
OECD (Orgnisation for Economic Co-operation and Development);. (2002). Highlights of the
OECD information technology outlook 2002. Paris: OECD Publication service.
O'Reilly, T. (2005, September 30). O'Reilly. Opgeroepen op October 24, 2011, van What is Web
2.0:
Design
patterns
and
Business
models
for
the
next
generation
of
Software:
http://oreilly.com/web2/archive/what-is-web-20.html.
Päällysaho, S., & Kuusisto, J. (2008, September 12). ICCWBO (International Chamber of
Commerce: The World business organization). Opgeroepen op May 8, 2012, van Intellectual
Property protection in service sector:
http://www.iccwbo.org/uploadedfiles/ICC/policy/intellectual_property/pages/IP%20protection%20i
n%20service%20sector.pdf.
Parasuraman, A., Valarie, Z., & Leonard, L. B. (1988). SERVQUAL: A Multiple-Item Scale for
Measuring Consumer Perceptions of Service Quality. Journal of Retailing , 13-40.
Patton, M. (2002). Qualitative research and evaluation methods. Boston: Sage Publications.
Pelham, A. (2000). Market orientation and other potential influences on performance in small and
medium-sized manufacturing firms. Journal of Small Business Management , 38 (1), 48-67.
Perry, C. (1998). Processes of a case study methodology for postgraduate research in marketing.
European Journal of Marketing , 32 (9), 785-802.
96
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Pohl, K., Bockle, G., & van der Linden, F. (2005). Software Product Line Engineering
Foundations, Principles, and Techniques. Heidelberg: Springer.
Regnell, B., Host, M., Nat och Dag, J., Beremark, P., & Hjelm, T. (2001). An Industrial Case
Study on Distributed Prioritisation in Market-Driven Requirements Engineering for Packaged
Software. Requirements Engineering 6 , 51-62.
Roberts, E. (1990). Evolving toward product and market-orientation: The early years of
technology-based firms. Journal of Product innovation management , 7 (4), 274-287.
Ruhe, G., & Saliu, M. (2005). The art and science of software release planning. IEEE Software ,
22, 47-53.
Sawyer, S. (2000). Packaged software: implications of the differences from custom approaches to
software development. European Journal of Information Systems , 9 (1), 47-58.
Schach, R. S., & Tomer, A. (2000). Development/maintenance/reuse: software evolution in
product lines. Proceedings of the first conference on Software Product Lines: Experience and
research directions , 437-450.
Shapiro, C., & Varian, H. (1998). Information Rules: A strategic Guide to the Network Economy.
Boston: Harvard Business School Press.
Shaw, J. (1995). A schema approach to the formal literature review in engineering theses.
System , 23 (3), 325-335.
Simley, J., & Mason, H. M. (2012, April 23). Corporate Divestiture. Opgeroepen op July 30, 2012,
van Reference for Business: http://www.referenceforbusiness.com/encyclopedia/ConCos/Corporate-Divestiture.html#b.
Simula, H., Lehtimäki, T., & Salo, J. (2008, June 15-18). Re-thinking the product – from
innovative technology to productized offering. Proceedings of the 19th International Society for
Professional Innovation Management Conference , pp. 1-13.
Sink, E. (2006, 07 22). The business of Software. Opgeroepen op October 15, 2011, van Erik
Sink: SouceGear Founder: http://www.ericsink.com/bos/Business_of_Software.html.
97
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business
Review , 137-146.
van de Weerd, I. (2009). Advancing in Software Product Management: An Incremental Method
Engineering Approach. Utrecht: Utrecht University.
van de Weerd, I., & Brinkkemper, S. (2007). Meta-modeling for situational analysis and design
methods. In M. Syed, & S. Syed, Modern Systems Analysis and Design Technologies and
Applications (pp. 35-54). Hershey: IGI Global.
van de Weerd, I., Bekkers, W., & Brinkkemper, S. (2010). Developing a maturity matrix for
Software Product Management. Proceedings of the 1st International Conference on Software
Business (ICSOB 2010) , 76-89.
van de Weerd, I., Bekkers, W., & Brinkkemper, S. (2010). Developing a maturity matrix for
Software Product Management. Proceedings of the 1st International Conference on Software
Business (ICSOB 2010) , 76-89.
van de Weerd, I., Brinkkemper, S., Nieuwenhuis, R., Versendaal, J., & Bijlsma, L. (2006).
Towards a Reference Framework for Software Product Management. 14th IEEE International
Requirements Engineering Conference (RE'06) , 319-322.
van den Akker, M., van Diepen, G., & Versendaal, J. (2005). Flexible Release Planning Using
Integer Linear Programming. Proceedings of the 11th International Workshop on Requirements
Engineering for Software Quality , 13-14.
Vandermerwe, S. (1995). The Process of Market-Driven Transformation. Long Range Planning ,
28 (2), 79-91.
Vargo, S. L. (2004). The Four Service Marketing Myths : Remnants of a Goods-Based,
Manufacturing Model. Journal of Service Research , 6, 324-335.
Voss, G., & Voss, Z. (2000). Strategic orientation and firm performance in an artistic environment.
Journal of Marketing , 64 (1), 67-83.
98
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
Weis, M., & Sirbu, M. (2000). Selected Intellectual Property Issues in Standardization. In K.
Jakobs, IT Standards and Standardization: A global perspective (pp. 63-79). London: Idea Group
Publishing.
Winch, G. (1998). Zephyrs of creative destruction: understanding the management of innovation
in construction. Building Research and Information , 2 (5), 268-279.
WIPO. (2011, July 23). What is Intellectual Property. Opgeroepen op October 20, 2011, van
World Intellectual Property Organization: http://www.wipo.int/portal/index.html.en.
Xu, L., & Brinkkemper, S. (2007). Concepts of Product Software. European Journal of Information
Systems (EJIS) (16), 531-541.
Yin, R. (2003). Case study research: Design and methods (3rd edition). Thousand Oaks, CA:
Sage.
Yin, R. (1984). Case study research: Design and methods. Newbury Park, CA: Sage.
Zainal, Z. (2007). Case study as a research method. Jurnal Kemanusiaan , 1-6.
Zeithaml, A. V., Berry, L., & Parasuraman, A. (1996). The Behavioral Consequences of Service
Quality. The journal of marketing , 60 (2), 31-46.
99
Master’s thesis
Transforming from developing customer specific software to standard product software
Kadri Guvendiren – Student Number 3376346
16. Appendix A – Dimensions
Service business
Stages
Independent projects
Hybrid Business
Product basis
Product business
Reuse across projects
Product recognition
Product platform
Customized software;
consisting of large set of
custom features across
projects
Meet the customer needs;
amortize costs and reduce
time to develop and increase
quality/efficiency by software
component reuse
Customized software; consisting
of large set of standard features
across projects
Standardized software with
large customized layer per
customer
Standardized software;
emerging product; customized
layer per customer
Meet the customer needs but
create product(s) based on
standard features and focus on
market potential for the
product(s)
Meet the customer needs but
create a generic product
platform for a market; focus
on partnering and long term
planning to gain market share
Meet the customer needs but
focus on bringing the
product(s) for large set of
customers in the market,
identify product lines,
determine your pricing,
positioning and product
strategy
Identify competitive and
alternative offerings in the
market and develop strategy
for winning against the
competition (assess the
technology inside and outside
the organization)
Releases designed per
customer
Customizable product
Standard product
Dimensions
Software
Customized software
Business focus
Meet the customer needs
within budget and time,
contractual fulfilment
(customer satisfaction)
Market goals
(Not important) it is based
on Interaction, relationship
and networks, no reserved
budget for marketing
(Not important) obtain
components from different
vendors to integrate with for
customer specific solutions
Marketing becomes important.
Identify target market, define
product goals and determine
the entry mode and make
win/loss analysis
Discover problems in the
target market by interviewing
customers, recent evaluators
and potential customers to
capture market requirements
for the product
Lifecycle
Maintenance per customer
Maintenance per customer
Maintenance per customer
(including product platform)
Software development
philosophy
Requirements gathering
Waterfall
Maintenance per customer
based on structured
component-based software
engineering process
Waterfall, Component-based
Waterfall, Component-based
Gather requirements from all
customers and store them in
one central place
Requirements selection
Select all customer
requirements per project
(more or less fixed list)
Development teams
Project focused, people are
assigned to multiple
projects
Stakeholder involvement on
development
High external, barely any
internal
Gather requirements for
each customer and match
the requirements with
reusable components
Select all customer
requirements per project
(more or less fixed list) and
select the custom reusable
components/features to
implement the requirements
Project focused, people are
assigned to multiple projects,
developing in a way to
enable reusability
High external, barely any
internal
Waterfall combined with
iterative development
Gather requirements from all
customers and start involving
internal stakeholders
Gather requirements for
each customer
Standardized product
software; customizable for
customers by adding small
customized layer
Bring the product(s) to the
market as customizable for
each customer and provide
support services.
Standardized product,
product is fully configurable
Focus on branding and
differentiation and aim at
selling services based on
business-to-business
relationship
Focus on product, price,
place and promotion (4P’s)
and 4C’s (Customer, Cost,
Convenience and
Communication) and
branding/ differentiation
Releases based on fixed
release dates; equal for all
customers (not customizable)
Releases based on fixed
release dates for the entire
market
SCRUM (Agile) development
SCRUM (Agile) development
Gather requirements from
entire market; all internal
stakeholders and all
customers
Optimal selected subset of
market requirements
(roadmap based) and
requirements for
customization
Gather requirements from
entire market; all internal
and all external stakeholders
Bring the product(s) to the
market and increase market
share by selling licences
Select all customer
requirements per project (more
or less fixed list) and identify the
standard existing
features/components that meet
the requirements
Project focused, people are
assigned to multiple projects,
start to form product team
Select requirements for
product platform and select
(large quantity of) customer
requirements
Waterfall combined with
iterative development
Gather requirements from all
the internal and external
stakeholders; start looking at
market trends
Focus on selecting
requirements for product
(roadmap-based) and subset
of customer requirements
Product focused, developing
the core product platform from
technology
Product focused, sharing
product vision to bring the
product to market
Product focused, sharing
product vision to sell the
product on market
Product focused, sharing
product vision to sell the
product to market
High external, low internal
High external, medium
internal
Medium external, medium
internal
Medium external, high internal
Low external, high internal
Table 28 - Dimensions
100
Master’s thesis
Transforming from developing customer specific software to standard product software
Optimal selected subset of
market requirements
(roadmap based)