Jan Katz
A Plan for Successful CRM Deployment in a Case Company
Helsinki Metropolia University of Applied Sciences Master’s Degree
Industrial Management Master’s Thesis
6 May 2021
This has been an incredible journey to achieve my Master’s degree. I would like to thank my supportive wife and children. They had tremendous understanding when the study was in its most intense period and gave all their support even though I studied late in the evenings. They believed in me when I didn’t. Thank you.
I also want to thank Dr. Thomas Rohweder and Sonja Holappa for helping and guiding me with this thesis. This thesis was a mental challenge for me and support from the teachers was invaluable to achieve this and finalize the Master’s Thesis.
Jan Katz Helsinki May 6, 2021
Author Title
Number of Pages Date
Jan Katz
A Plan for Successful CRM Deployment in a Case Company 58 pages
6 May 2021
Degree Master of Engineering
Degree Programme Industrial Management
Instructors Dr. Thomas Rohweder, Principal Lecturer Sonja Holappa, MA
This study focused on the Customer Relationship Management (CRM) system implementa- tion. CRM systems are used in companies to develop customer relationships and co-create value with customers. The CRM system affects the companies’ strategy and everyday pro- cesses. Therefore, implementing a CRM system correctly and effectively can increase the value for the company. This thesis focused on the CRM system project, how it should be carried out and what needs to be considered during the project. The outcome of this thesis is a comprehensive plan for the project in the case company.
This thesis started with exploring relevant literature, which was the basis for the initial project plan. Then, the conceptual framework was built against relevant literature. The contents of the conceptual framework utilizes select ideas from management and CRM implementation literature to tackle the challenge. After the conceptual framework, a current state analysis was carried out by interviewing the project stakeholders on a previous implementation pro- ject. The initial plan of the project was created based on literature and CSA results. The initial proposal was validated with stakeholders and the plan was developed further to its final form, which included the comments of the project group.
This study indicated a readiness for the implementation and created frames for a successful CRM system implementation. The study suggests proven methods which can be used during the CRM system deployment. Implementing the CRM is not a small investment which is why the case company would benefit from using this thesis as a guideline.
Keywords CRM implementation, Project deployment
Contents Preface Abstract
1 Introduction 1
1.1 Business Context 2
1.2 Business Challenge, Objective, and Outcome 2
1.3 Thesis Outline 3
2 Method and Material 4
2.1 Research Approach 4
2.2 Research Design 5
2.3 Data Collection and Analysis 6
3 Best practice of CRM system deployment from literature 9
3.1 Project impementation components 9
3.1.1 Strategy 9
3.1.2 Project KPIs 10
3.1.3 Management 11
3.1.4 Technology 13
3.1.5 People 14
3.2 Project implementation process 15
3.2.1 Initiation Process 15
3.2.2 Planning Process 16
3.2.3 Executing Process 18
3.2.4 Rollout Process 20
3.3 Conceptual framework 20
3.3.1 Initiation 21
3.3.2 Planning 22
3.3.3 Execution 22
3.3.4 Rollout / Support 23
3.4 Summary of the conceptual framework 23
4 Analysis of previous system implementation 25
4.1 Overview of how this data stage was conducted 25 4.2 A detailed description of previous system implementation 26 4.3 Analysis of strengths and weaknesses in previous system implementation 27
4.3.1 The initiation stage of the previous implementation 27 4.3.2 The planning stage of the previous implementation 28 4.3.3 The execution stage of the previous implementation 30 4.3.4 The Support / Rollout stage of the previous implementation 31 4.4 Summary of key plusses and minuses in previous system implementation 32 5 Building a CRM implementation plan for Case Company 37
5.1 Overview of the proposal building stage 37
5.2 Initiation stage 38
5.2.1 KPI’s 39
5.2.2 Organizational assets 39
5.2.3 Business case 39
5.3 Planning Stage 40
5.3.1 Project roles 40
5.3.2 Management 40
5.3.3 Integration plan and preparation / scheduling 41
5.3.4 Document plan 41
5.4 Execution stage 41
5.4.1 Environment set-up 42
5.4.2 System integration 42
5.4.3 Piloting/Testing 42
5.5 Support / Roll-out stage 43
5.5.1 Training 43
5.5.2 Support 43
5.5.3 Roll-out 44
5.6 Summary of the initial proposal for a CRM implementation plan 44
6 Validation of the Proposal 47
6.1 Overview of the Validation Stage 47
6.2 Feedback of the plan 48
6.3 Validating proposals 48
6.3.1 Support from management 49
6.3.2 Management and user incentives 49
6.3.3 Training plans for the users 50
6.4 Final Proposal 50
7 Conclusions 53
7.1 Executive Summary 53
7.2 Next Steps and Recommendations toward Implementation 54
7.3 Thesis trustworthiness evaluation 55
7.4 Closing Words 57
References 58
1 Introduction
Companies often have difficulties understanding customer needs and how data collected regarding customer needs can be analyzed. In general terms, sales can be divided into two sales segments, web sales, and project sales. Web sales are faster where custom- ers are purchasing goods from the web. The stock value in web sales is bigger and the rotation of goods is faster. Also, margins of goods are lower than in project sales. Project sales are long-term sales, and they can take several years to create and close. Margins are better but the sales cycle is slower. Also, the delivery time is usually longer than with stocked items. The customer segments are different between these two types of sales.
Most of the long-term sales customers are manufacturers and web sales customers are smaller maintenance companies. Of course, there are exceptions, and this is a rough division.
One tool used to understand customer needs is the CRM system, which provides real- time data about customer behaviour and needs to the company. CRM also helps the company to measure internal and external key performance indicators, KPIs. An overall CRM system can provide sales reports, customer reports, and links between them.
This thesis focuses on the implementation plan for a successful CRM system (Customer Relationship Management) deployment, and how the new CRM can be deployed suc- cessfully through the organization. This paper aims to create a plan of implementation and proposal for CRM deployment.
1.1 Business Context
The case company was established in the 1960s and has a long history of importing, selling, and exporting electronic components, and measuring units to various customer groups internationally in Finland, Baltics, and Russia. The company also provides ser- vices, maintenance, and technical support to customers. About 260 employees are work- ing for the company in its business area. At the moment the annual turnover is about 40 million euros. The main warehouse serves all subsidiaries in its business area.
The company is known among customers thanks to its long history. The company has served its customers for a long time and some customers have been loyal since the company was established.
1.2 Business Challenge, Objective, and Outcome
The business challenge in this thesis is that competition between companies has tight- ened since many companies have been developing their knowledge to reach customers better and serve them in a more customer-oriented way. This phenomenon has forced the case company to rethink how to approach customers in a new way and thus create new ways to compete with competitors. The case company knows that understanding customers better and how they act is essential in order to obtain a better view of custom- ers' needs. KPIs, generated by CRM, indicate to the company which segments are most profitable and what kind of actions the company needs to take. The problem is that selling and customer data have not been analyzed earlier and decisions have been made mainly by “shooting from the hip”.
The company has now decided to deploy a new CRM system to provide better service and value for customers. The new CRM system is expected to help the company to develop customer relationships and produce better customer data for the management.
Accordingly, the objective is to propose an implementation plan for a successful CRM deployment in the case company.
The outcome of this thesis is to create an implementation plan for successful CRM de- ployment.
1.3 Thesis Outline
The study was conducted by analyzing earlier system integration projects in the com- pany. The last change was about 3 years ago which was analyzed in this thesis. A cur- rent state analysis (CSA) was carried out by investigating the earlier implementation in light of relevant literature. The CSA is based on interviews. The results of the CSA were later used for building the proposal for deploying and implementing the new CRM system in the case company.
This thesis is written in 7 sections. The introduction is the first section. The second sec- tion discusses the methods and data used in this thesis. Section three discusses best practice of new system implementation based on relevant literature. The fourth section analyzes the strengths and weaknesses of the previous system implementation. The fifth section introduces the initial proposal for implementing the new CRM system. The sixth section concentrates on management feedback on the initial proposal in order to build the final solution. Last, Section 7 provides the summary and recommendations of this project.
2 Method and Material
This section discusses the research method and approach used in this thesis. This sec- tion first describes the research approach for its core features and secondly it explains the 5-stage research design for this thesis. Thirdly, this section explains how data was collected.
2.1 Research Approach
Kothari (2004) declares that “research has its special significance in solving various op- erational and planning problems of business and industry”. Kothari states that there are different ways to deploy research. It depends on what kind of research study is in ques- tion. As Kothari mentions, research approaches can be divided into two main groups, Qualitative and Quantitative. (Kothari 2004: 2-6)
The qualitative approach to research is based on behavioral science where different fac- tors are present. Qualitative research also includes personal deeper interviews, projec- tive techniques, and group sessions. The result from interviews reveals motivation and usually, it is called “Motivation Research”. (Kothari 2004). Therefore it is an important part of the research for changes and deployments.
A quantitative approach is based on numbers or amounts. The quantitative approach is used to measure phenomena quantity, like the event cycle (Kothari 2004: 3). Quantitative research results can be used qualitative way. By integrating both methods, qualitative and quantitative, the research findings can support each other and strengthen the validity and quality (Saunders et al. 2009: 123). As Figure 1 shows techniques and procedures are connected to different methods.
Figure 1. Research philosophies and approaches onion model (Sanders et al. 2009: 138) This thesis focuses on creating an implementation and deployment plan for a new CRM system. Therefore, the qualitative approach will be used in this study. The deployment of the new system needs interaction between different organization groups. Interviewees are used to reveal the current state of readiness and skills to implement a new CRM system.
2.2 Research Design
This research is implemented in 5 stages. Figure 2 below shows the research stages in detail. The research is built by first establishing an initial project plan. The initial plan gives a scheduled timeline for the project. It also defines an initial structure for CRM implementation and deployment. The scheduled and divided sections help stakeholders, management, and project group, to keep different issues under control.
Figure 2. Research design
As shown in Figure 2, the second stage is exploring the best practice of CRM deployment from literature. The literature review offers the best deployment tools for the project to implement CRM successfully. Best practice can be mirrored to the third stage, where the case company’s previous system implementation is analyzed. The data analysis results offer potential readiness for creating the CRM implementation and deployment plan. The focus is on project components and project processes. The outcome of the third stage is a summary of the existing potential for new CRM system deployment. Potential data, for implementation, establish the frame for the project.
The fourth stage focuses on the implementation plan. This is done with the company’s project stakeholders and the outcome of this stage is a proposal plan for implementing the CRM project.
In the fifth stage, the proposal is validated with the management, and based on their feedback, the final plan is created. The final plan is the outcome of this Master’s thesis.
2.3 Data Collection and Analysis
This study gathered data from different data sources at different stages of the study.
Data was gathered by interviewing participants holding different positions in the case company and from documents, as well.
The purpose of collecting data 1 and analyzing was to understand the weaknesses and strengths of resources and implementation readiness for other system changes. Data 1 was conducted for the CSA, which includes the current potential for the project, manage- ment, and project group.
The data collection methods, in more detail, are shown in Table 1 below. There were three data collection rounds and each round included different variables of interviews and questionnaires.
Table 1. Summary of collected data
Participants / role
Data type Topic, description Date, length
Documented as
Data 1, for the current state analysis (Section 3)
1 Respondent 1:
IT department
Telephone in- terview
The case company previous in- tegration project.
- Design
- Definition of project - Implementation - Support
January 2021
Field notes
2 Respondent 2:
System sup- porter
Telephone in-
terview Co-operating with project January
2021 Field notes
3 Respondent 3:
Manager of us- ers
Telephone in-
terview Interview about current process based on the respondent’s ex- periences
January
2021 Field notes
Data 2, for Proposal building (Section 5)
4 IT manager CDO
Teams meet-
ing Proposal building with project
stakeholders April
2021 Field notes
Data 3, from Validation (Section 6)
5 CDO Teams meet-
ing
Validation, evaluation of the Pro- posal
April 2021
Field notes
6 IT manager Teams meet-
ing Validation, evaluation of the Pro-
posal April
2021 Field notes 7 Marketing Man-
ager Teams meet-
ing Validation, evaluation of the Pro-
posal April
2021 Field notes
As seen in Table 1, Data 2 was collected by interviewing the project group in a workshop.
The author of this thesis presented the findings from best practices and the analysis results regarding the company’s previous system implementation to the project group.
The group was then asked to co-create the initial proposal for the CRM implementation plan based on those findings.
Data 3 was collected for validating the initial proposal. This was done by organizing a meeting and interviewing the management after showing the co-created initial proposal to them and explaining it to them.
The next section focuses on exploring best practices on CRM system deployment as discussed in relevant literature.
3 Best practice of CRM system deployment from literature
This section discusses the best practice of new system implementation from relevant literature. The section discusses project implementation and its components. The litera- ture findings cover the project process from the beginning to the end. The last subsec- tion, the Conceptual Framework, is written based on these findings and it is mirrored to best practice literature.
3.1 Project impementation components
Project implementation includes many different components which can affect a project positively or negatively. As Goldenberg (2008: 195) defines, implementation includes people, processes, and technology. These components are mixed in the system integra- tion. CRM is a business approach that integrates people, processes, and technology to maximize the relationship with customers. Buttle (2004: 34) defines CRM as a core strat- egy that integrates processes, functions, and networks to create better value for targeted customers. The purpose of CRM is to create high-quality customer data for a company that is provided by IT.
3.1.1 Strategy
According to Goldenberg (2008), the company often embarks on CRM initiatives without having a clear strategy of where they are going or where they need to be. Those com- panies usually end up with CRM results below expectation. CRM generates data that can be used to increase the satisfaction of delivered services and products (Jones et al.
2008: 121). More satisfied customers give a possibility to enlarge the proportion of inter- action. This means a better “share of wallet”. As the relationship develops and trust in- creases, system integration between the customer and supplier reduces costs. A satis- fied customer is also more loyal and the threshold to change supplier increases (Knox et al. 2003: 103).
Many sources warn about the implementation of CRM. There are many pitfalls like im- plementing CRM before a clear customer strategy (Reicheld et al 2002: 3). Strategy is the direction which the company decides to take. If that is not determined, CRM imple- mentation has no clear course. Therefore the strategy of CRM vision is an important step
of the implementation. If the strategy and definition of CRM are not clear to the execu- tives in the company, the project will be boosted in a different direction depending on who is driving. According to Goldenberg (2008: 862), for example inside a company, there might be different views of CRM and it should be formulated to meet at every level.
According to Payne et al. (2005: 170), a business strategy that is related to CRM should be determined before starting the implementation of the CRM system.
3.1.2 Project KPIs
The project KPIs (Key Performance Indicators) is a valuable tool for measuring project tasks, results, and success. Complex projects have multiple challenges but all issues have some kind of a solution. Some solutions are better than others. Project Manage- ment point of view, resolving the issue or tackle barriers, during the project with KPIs is easier and more effective than just guessing the best solution. (Kerzner 2017).
Reflecting solutions to KPIs, decisions are efficient and targeted. When KPI’s are se- lected for measuring the project, according to Kerzner (2017) KPIs will:
▪ Allow for better decision making
▪ Improve performance on the project
▪ Help identify problem areas faster
▪ Improve customer–contractor–stakeholder relations
KPIs are serving project stakeholders as an early warning signal, for example, if an un- favorable risk is coming true or the project is skewing from its target, it alarms the project group to take corrective action. At the same time with a warning signal, defined indicators give a clear picture of what is important in a project. Some companies select KPIs based on the Pareto principle. It states that 20 percent of indicators cover 80 percent of the project. (Kerzner 2017).
Effective KPIs share certain core attributes. One used approach for establishing KPIs is called the SMART criteria technique. It stands for (S)specific, (M)easurable, (A)ttainable, (R)elevant, and (T)ime-bound. (Kezner 2017)
▪ S = Specific: The KPI is clear and focused toward performance targets or a busi- ness purpose.
▪ M = Measurable: The KPI can be expressed quantitatively.
▪ A = Attainable: The targets are reasonable and achievable.
▪ R = Realistic or relevant: The KPI is directly pertinent to the work done on the project.
▪ T = Time-based: The KPI is measurable within a given time period.
As Kezner warns (2017), Key Performance Indicators can affect the project negatively if too many indicators are selected or if the indicators are impractical. It can slow down processes because of excessive measurement and reporting.
3.1.3 Management
Management commitment to the strategy is one key factor of success. Getting Manage- ment and workgroups to work together, identifying work design, redefining processes, and creating incentives, increase success possibilities by 40%. If the company wishes to increase the possibilities more, this needs to include a disciplined approach to data and projects. If considering the odds to success, they are weak unless these organizational questions are tackled. Organizational issues might be culture, change management, pro- cesses, company governance, and alignment (Williams 2014: 130).
As seen in figure 3, sponsorship has a big role in changing culture and people. Sponsor- ship can effectively influence the failure or success of CRM implementation. Sponsorship is not equal to permission.
Figure 3. How Top Organizations Make CRM Stick (Williams 2014: 130)
Funding management is not enough to reach a successful CRM implementation. As fig- ure 3 shows Funding is only a small part of the process.
Change management is about managing processes, technology, the structure of the or- ganization, and assignments of work. The purpose of managing these is to reduce the risks and costs and optimize the benefits for the company. According to Murthy (2007:
23), there are two dimensions of change management. One dimension includes opera- tional and strategic factors and the other includes technology, process, and people. As seen in figure 4, the demand for managing the different parts of tasks takes time, de- pending on the connection between technology, process, or people. The figure illustrates the demand level of management and how it is related to the impact of business versus time to execute.
Figure 4. The dimensions of change management, based on Murthy (2007)
As figure 4 shows, the strategy level of change management has a greater impact on business and how it affects the company’s planned strategy. At the operational level, the impact has a lesser effect on business. The difficulty level of change management is described at the horizontal level. The technology, processes, and people are the seg- ments where change management difficulty and time are committed.
From the system integration point of view, technology is a small part of the change. It is the easiest and fastest to implement. The hardest change concerns people’s way to work. Some salespersons might say “I don't have time to enter the information into the system” (Murthy 2007: 2). This indicates challenges for managers to overcome this is- sue. People management takes time and skills to implement change at the strategic and operational levels.
3.1.4 Technology
Systems are usually integrated with other applications and functional areas to provide better and more accurate data from and for the customer. As seen in Figure 5, the CRM system is a contact point between different functions. CRM system is a node between customer and companys internal functions. Touchpoints can be the companies websites,
email, or customer call center. Traditional touchpoints are retail stores and service de- partments.
Figure 5. Application links between different functions Chen et al (2003: 674)
As depicted in Figure 5, customers may be dispersed globally, and they contact the company through different electronic and traditional touchpoints. CRM technology helps the organization to create better management information in terms of planning and con- trolling business and services through the organization (Newby et al. 2007: 103).
3.1.5 People
According to Goldenberg (2008), people are 50% of the overall success. This is the point where the project can fail or succeed. People are naturally resistant to change, and therefore well-done system implementation planning and committing people to change is recommended. Too often companies communicate and create training sessions just right before the system launch. Goldenberg (2008) declares successful initiatives include the communication plan before the execution of the project takes place. This means time needs to be taken for planning and considering how communication and training will affect users. Without planning communication and training, users might not feel the value-add of the system. Goldenberg (2008) presents the 3X factor, which is related to user adoption. The 3X factor means “one value in, three value out”. When the user adds one piece of value to the system, the system will deliver three value pieces out. As the system is planned and created with this philosophy, the adaptation success rate in- creases.
3.2 Project implementation process
The Project Implementation consists of four general process stages, i.e. Initial, Planning, Execution, and Outcomes from a project. These four major blocks are run by the project resources, such as the Project Manager, and Project board at a higher level and Project group in Planning and Execution stages (Zwikael et al. 2019). The four stages are ex- plained in more detail below.
3.2.1 Initiation Process
The initiation process is the first step for establishing the project. As seen in Figure 6, the Initiation process consists of 4 main steps.
Figure 6. Initiation step of the project (Zwikael et al. 2019: 204)
These main steps inside the initiation process, are Identification, Definition, Analysis, and Packing. The outcome of this defines the Business case for the project.
The first sub-process step (identification) identifies a possibility or an idea to develop a company's business. It can come from a supplier, vendor, or customer. At this stage, the prospect of this project needs to be stated if it is worth for the company. The first step is
to seek the answer to the question “Is this project a worthwhile investment”? If the iden- tification of the project gets a green light, it moves to the next level.
The second step is Definition. The Definition stage defines the overall shape of the pro- ject, including lists of targeted outcomes, outputs, and processes. In this stage, core parameters like KPI’s are set for the project. After the Definition stage follows The Anal- ysis step. During the Analysis step, various aspects of the project need to be considered.
This step includes a high-level plan, stakeholders, and governance arrangements for the project. Before starting the project, the company also needs an analysis of the risk, is- sues, and tentative estimate of the cost and duration. The end of the Initiation stage is the final estimation of the project character, effectiveness, and possibility for the com- pany. At the fourth step, packaging, the outcome of the analysis is incorporated with a definition to a business case. These things together define a final business case for the company (Zwikael 2019).
3.2.2 Planning Process
After the Definition process with its steps are completed, the Planning process of the project takes a place.
When the project starts, defined roles and responsibilities are a success factor. As Barker writes (Barker 2009: Chapter 3), some roles might support different levels of the project.
It can support “big picture position” through the Team leaders, who oversee a smaller part of the daily process. According to Barker (Barker 2009: Chapter 3), project team roles are one key point of executing a successful project.
Management of the project or project team consists of different roles. The Project Board, which needs to be established at an early stage is responsible for the whole project. The Board has the responsibility for the availability of budget, and a clear scope of the project.
The Project Board comprises three roles in this team: Executive, Senior User, and Senior Supplier roles. These roles are responsible for the failure or success of the project. Their role includes showing direction and delegating management and resources to the pro- ject. (Barker 2009: Chapter 3).
One of the key roles of the Project team is Project Manager. The Project Manager is appointed to look after the day-to-day tasks of the project, and he or she is responsible
to execute the processes in the project, therefore planning is also done by the Project management in the early stage of the project. The Project Manager can delegate respon- sibility for certain work to the project members or Team Managers. If there are no Team Managers, which is optional in projects, the Project Manager can supervise the team directly. (Barker 2009: Chapter 3). According to Murthy (2007), The responsibility for the change control and project implementation lies on the Project Managers' shoulders. The Project Manager is the chair of the project control group and the support for the project comes from the Project board (Zwikael et al. 2019).
Figure 7. The organizational structure of the project management team (Barker 2009: Chapter 3).
As seen in Figure 7, this structure comprises the roles of Change Authority and Project Assurance. These roles are carried out by the Board of the project. These roles are sup- portive for the project and Project Management.
In the Planning process, the person responsible for the different parts of the project is established. The used method to establish responsible roles is to use the RASCI model.
The RASCI matrix shows task areas and who is responsible for the tasks. RASCI is an abbreviation from (R)esponsible, the person or position responsible for accomplishing the step of the project. (A)ccountable is the person or position accountable for ensuring
the step of the project is done on time with defined quality. (S)upport, is a person who has specific knowledge or ability. (C)onsulted is a person or position that is consulted before any critical action on the project is made. (I)nformed is a person who should be made aware after the task is completed.
Table 2. Example of RASCI model in the project, based on Katzman (2016)
Step Project Board Project man-
agement IT department System owner Integration
Plan I R, A S
Prepare /
Schedule A I R
Document
plan R
System inte-
gration I R C
Pilot / Testing A I,A R
According to Zwikael et al. (2019), after appointed roles and responsibilities are defined to the project, the Project Management plans the project in detail. It includes details of technical issues, tasks, and scheduled milestones. The documented plan serves the pro- ject during the implementation. The output of the plan is the baseline of the project and it is followed through the stages. When the plan is done properly it shows to the project team, to the project board, and other participants when and how the asks are carried out.
This reduces the uncertainty of resources and how long the task period takes in a specific stage.
3.2.3 Executing Process
According to Zwikael et al. (2019), in the Executing process, a planned project will be deployed. The process of this stage is iterative and the target is the planned outcome.
This stage might need external resources, which is recognized in the Initiation stage.
Typically during this stage, the project needs the highest amount of resources (Wilsson 2014). Most of the risks occur in this phase because risk events are usually related to work activities.
Figure 8. The project Execution phase in the ITO model (Input-Transform-Outcome) (Zwikael et al. 2019)
The main purpose of the Execution stage is to produce, deliver, and deploy the project's outputs. As seen in the ITO model figure above, the execution stage is a process. This process, according to Zwikael et al. (2019), is carried out in an iterated way. Although the execution stage is done by the script, which is executed in the Planning stage, chang- ing circumstances tend to redirect the project away from the planned outcome. There- fore, the processes in projects are handled in iterative cycles.
If there is a risk, where the project is distorting from its target, it can be prevented with the Project Execution Management cycle (PEM) process. The subprocesses of PEM are the Project environment surveillance (PES), Project Execution Control (PEC), and Pro- ject baseline revision (PBR). These subprocesses are executed sequentially during the Execution stage.
PES is the surveillance of external things such as stakeholders, and the risk from the outside of the project. The PES process tries to seek and prevent the problems from outside, which might affect the result of the project. This process helps the project group to evaluate the changes regularly, which might affect the outcome. PEC is controlling the project direction. Repeatedly asking if the project is proceeding as planned and if the plan is achievable keeps the project's focus on the plan. The third subprocess is PBR, which enables to adjust the decisions regarding the project and outcome. Sometimes the project can drift into a situation where it is out of control and the only rational decision is to set new parameters to the project. (Zwikael et al. 2019).
3.2.4 Rollout Process
After Executing process, the final process takes place. According to Zwikael et al. (2019), the Rollout process produces the final outcome from the project. If everything goes well during the project, the outcome is the product or service as it was planned and originally founded. The rollout stage prepares the project to be closed. The project manager has a main role in the rollout stage. The project manager is accountable for the delivery of the planned outputs. The project is fulfilled when all outputs have been delivered as planned. (Zwikael et al. 2019).
According to Goldenberg (2008), before closing the CRM implementation project, there needs to be a plan for the training and support activities. Goldenberg (2014) also warns not to underestimate the importance of the final step of CRM implementation. According to Zwikael et al. (2019), the project can be closed when target outcomes have been secured and handover to the client or system owner has taken place.
3.3 Conceptual framework
The conceptual framework for project implementation presented in this section is based on section 3 literature and widely used practices in ICT companies. The conceptual framework for this thesis contains four main steps. The first step is the Initiation stage, where the business case is defined and the purpose of the project for the company is estimated. This stage also includes strategy, KPIs, and organizational assets definitions.
The second step is the Planning stage. In this stage, the project is established, and the main tasks are project roles, Management, System integration readiness, prepar- ing/scheduling, and plan documentation of the project. The third step is the Execution stage, which includes environment setup, system integration, and pilot stages. The fourth step is the rollout and support stage. It includes training, and support for users, and final integration documentation. The detailed steps are presented in Figure 9.
Figure 9. Conceptual framework of this study for project implementation
A detailed description of the Conceptual Framework shown in Figure 9 is written in the subsections below.
3.3.1 Initiation
The first step of the project is Initiation. The objective of this step is to define the outcome of the project. It’s described in more detail in section 3.4. Project initiation is the phase where the whole project justification is rejected or accepted. This phase includes sub- steps that define strategy and assets. Even if assets are defined at this point, they need to be evaluated again in the Planning step (Katzman 2016). KPIs for the project are selected and defined. KPIs are the measurement attributes for the different tasks. Before the initiation stage is ready, the KPIs are established. Basic indicators are budget and schedule. Budget KPI indicates how much money the company has spent on the project at a certain point. Schedule indicators reveal to stakeholders, where the project is going and how many percent of the project is done. Other indicators can be task change indi- cator, which reveals if there are too many changes versus planned tasks at a certain point. KPIs can be viewed as a warning system. These performance indicators assist Project Management to drive the project in the right direction and on time.
3.3.2 Planning
The second step of the conceptual framework is planning the project. According to Barker (Barker 2009), Project team roles are one of the crucial components of a suc- cessful project, see figure 9. Roles and responsibilities are established in this step of the project. At this point of the project, a system integration plan is created and it needs to meet budget and strategy standards. Scheduling is most important from a budget point of view. In the Planning stage project planning documents are also created which is part of communication across the project team. Without documentation, the project team can- not see the status of how tasks are progressing in the Execution stage.
In the Planning stage, Management for the project is defined. The Board of the project is established in the Initiation stage, but in this stage, the Project Manager and project team are committed to implementing a project. The project needs team leaders' assis- tance to implement the project as it is planned. Without team managers or users man- agement support, system implementation is doomed to failure. This also applies project board. If necessary support is not available, the Project Manager is left alone with the project. Thought management is initially defined in the Initiation stage, in the section Organisational assets, and in the Planning stage in the Project roles section, Manage- ment needs to be committed to delivering the project successfully.
3.3.3 Execution
The third step of the project is Execution. This step is the phase where the planned tasks are implemented. At this point, a technical integration plan is executed. In this case, there are third-party operations, and communication between all parties is established and scheduled. The quality of communication with all parties will affect the outcome of the execution stage. Communication with users and management is also important in the pilot stage.
The technical point of view in the Execution stage means setting up environmental facil- ities. According to Murthy (2007), the level of difficulty is low with technology, see figure 4. When this is done properly, the integration of the system will be smoother. If there is a third party involved in the integration, communication with all parties can complicate the implementation of the integration.
After integration, the Pilot step is executed. Piloting the product is testing it with users.
According to PRINCE2 quality inspection (Barker 2007) of a new integrated system can be used during testing. Quality of system is one criterion of the outcome. If it passes the quality criteria, which have been defined in the Initiation stage, the project goes forward to the final step.
3.3.4 Rollout / Support
The fourth and final step of the project is rollout and support. As everything else is done in the Execution phase, this phase contains training and support. The training sessions are planned in the Planning stage and here they are executed. As users start to use the new system, they should be aware of where they can get help if needed. Support is necessary regarding successful continuity. Well-planned support provides an atmos- phere where users feel supported and issues do not feaster. (Kostojohn et al. 2011)
According to Kostojohn et al. (2011), the transition from the Execution stage to the rollout stage and forward to the support stage is needed to be done quickly. If this is done fast, the reported issues can be tackled effectively and users do not need to use the buggy system for too long.
The last step of the Rollout / Support phase is documentation. The documentation has been made in the initiation phase by the project so in this stage documentation is final- ized by the project group. The documentation holds all data, which has been gathered during the project. It is a tool for cataloging issues and documenting their management.
The final version of the documentation also includes technical data and manuals for the users. Good documentation is one key task in the project. It provides specific data for the project group and the users. From the documentation, the project group can find, for example, planning flaws that caused integration issues. The documentation also helps the main users to provide better service and support for the users.
3.4 Summary of the conceptual framework
The conceptual framework contains best practices from different literature sources. The contents of this conceptual framework are adapted from different project management
and CRM implementation literature. These are used in ICT companies and some whole- sale companies. The literature from different sources shows the same sequence of pro- ject flow with certain variations. This literature review provided a useful framework that will be used in Section 4 of this thesis, when analysing the previous system implemen- tation in the case company, and also section 5 when co-creating the initial proposal for the CRM implementation plan.
4 Analysis of previous system implementation
This section discusses the findings of the previous system implementation. The previous implementation was conducted about 3 years ago. It was system integration to the ex- isting system. The purpose of this integration was to provide better service for customers and decrease the users' workload. This section contains four subsections. The first part of this section describes how data was conducted. The second part describes how the implementation was conducted. The third part analyses the strengths and weaknesses of the previous system implementation. And the last, fourth section is a summary of pre- vious implementation success.
4.1 Overview of how this data stage was conducted
The data was gathered from three different interviews. The interviewees were partici- pants of the project or from the support team for the project, as seen in Table 3.
Table 3. The previous integration project data gathering
Data gathering method Participants Focus area
Telephone interview Project Leader Project implementation:
Initiation Planning Execution
Support and Rollout Telephone interview Users supervisor Pilot / Testing
Training and Support
Telephone interview Project data support System environment Integration
The previous implementation project was not documented and thus everything in this analysis is based on the notes from the interviews.
4.2 A detailed description of previous system implementation
This section describes how the system integration project was conducted and how it was implemented. In this section, the description is mirrored with literature in section 3.
The integration project was started after the system provider suggested integrating the systems. The demand for integrating the systems was instant because the provider did not provide or support a separate system anymore. The system provider offered to inte- grate the system easily and on time. Scheduling was defined at this point by the board of the project and the third parties. The company project board, which was one person, estimated the meaning of the project for the company, and the project was accepted and it was passed to the IT department. At this point, it was not sure if a definition of the project or analysis of influencing factors was made. According to the interviews, a strat- egy analysis, KPI analysis, or how it will affect the business case was not done during the initial stage.
The project leader took the project from the project board and started to integrate it into the existing system with the two parties. One party was the existing supplier and one was the new system supplier. The internal teams, IT department, and the logistic depart- ment started to integrate the existing system, with third parties' help, and planned how new features will fit into it. The third parties delivered the required technical data and the testing period started. As everything was set up for testing, the project started to imple- ment the integration. Development between existing and new systems was made side by side as an ad hoc and accepting “good enough” as a method.
Communication between parties was occasional and was implemented via email. As the testing stages were at an acceptable level, the project moved to the next step. The pilot stage was not necessary, because everything was piloted during the integration project.
The final step of the integration project was rollout and final ending. The users started to use it under the guidance of the team supervisor. The training session was not arranged because the project and users did not see a necessity for it.
4.3 Analysis of strengths and weaknesses in previous system implementation
In this analysis, the previous implementation is compared to theoretical literature. The literature contained data studied from a long period and it suggested avoiding certain pitfalls of project implementation and barriers the project might meet. The analysis is divided into four parts. These parts are the same as figure 9 shows in section 3. The parts are Initiation, Planning, Execution, and Support / Rollout.
4.3.1 The initiation stage of the previous implementation
The initiation stage of the previous project started by the supplier of a third party as described in section 4.2. The detailed figure below shows, how the initial stage was con- ducted vs theory.
Figure 10. Comparison between previous system implementation and theoretical Initiation stages In literature, Strategy and KPIs should be defined in the Initiation stage. The interviews revealed this was not done. This means the project group did not have basic information on how the project will affect the company’s strategy and which KPIs are selected to
measure the project or how the project will be measured. These key elements are im- portant to define to run an integration project successfully. The lack of defining these steps results in another barrier to successful project implementation. When the third par- ties were driving the project from the beginning in the initial stage, the budget and sched- ule exceeded the defined limit.
Figure 10 above shows that the organization had assets for the project, such as budget, but not the personnel for the project implementation. At the start of the project, there were not enough resources to deploy system integration, and therefore the project was postponed.
The benefit of integration to business was understood well. The new system proved the effectiveness to the company and that was the main reason to show the green light to continue the project.
4.3.2 The planning stage of the previous implementation
The project was planned by the board. The third parties evaluated the systems and scheduled the project. The interviews revealed that management role was kept by the board and technical activities were left to the IT department. The real management dur- ing the project was in the third parties' hands, and the preparation and scheduling were made in the Initiation stage by the third parties.
There was no documentation plan for the project. Technical documentation was already available, and it was delivered to the company during the project.
Figure 11 shows a more detailed chart about the Planning stage. The project roles were defined by the project board and the third parties, but real management and project driver were third parties responsible.
Planning the system integration was not made properly. The technical resources of the company were left out in the Planning stage and the third parties evaluated the systems without the company's internal knowledge.
Figure 11. Comparison between previous system implementation and theoretical Planning stages
As the figure above illustrates, The Planning stage was inadequate. Project roles, prep- aration, and scheduling were made, but without the technical resources of the company.
The project leader was not given a budget, only the responsibility to succeed. This led to a situation where IT resources, and project leaders could not drive the project through the steps without struggling with resources, budget, and schedule. The following is a comment from the interviews:
“Communication and planning with other parties should have been more system- atic. This would have prevented the schedule and budget from being unreasona- ble.”
The project could not get support from management during the project. According to the interviews, support from the project board was tenuous. This was described and felt more like pressuring than supporting. Management support for the project is extremely im- portant. Lack of support can affect the result of the project and in the worst case, it can prevent the whole project's existence. When asked if there were available for extra re- sources or leverage for the project, the answer was:
“There was no extra resources availabe. Financial support came from the Board but at the same time, there was pressure on the project. There was more pressure from supporters even though they were defining the project at the beginning of the project.”
When the whole planning stage was conducted, the project took the next step of imple- mentation.
4.3.3 The execution stage of the previous implementation
The Execution stage was implemented after the Planning stage. The environmental setup was made by the third parties and the IT department participated in the project at this point. Due to the lack of project documentation, there is no certainty of how the environment setups were made. Therefore, this analysis is handled like it was not made.
Figure 12 below shows the comparison between the previous system implementation and the theoretical Execution stages.
Figure 12. Comparison between previous system implementation and theoretical Execution stages
The actual integration was made by the third parties with the assistance of the IT depart- ment. The testing period was deployed as ad hoc mentally. The system was tested dur- ing the development with users. The following comment was made regarding the partic- ipants:
“The project leader and logistics supervisor, with the support of the employees, as well as external suppliers participated in the testing.”
When the system was good enough, the project took the next step to the Piloting stage.
Piloting was run by the users, users team leader, and the IT project manager. After the system was developed to a tolerable point, the Support and Rollout stage was imple- mented.
4.3.4 The Support / Rollout stage of the previous implementation
The Support and Rollout were made at the end of the project. As mentioned in chapter 4, Training activities in the Rollout stage were not done. The users participated in the testing period, in the previous stage, therefore training was not necessary. System doc- umentation was not made either. According to different sources (Kostojohn et al. 2011, Zwikael et al. 2019), documentation of the project is crucial. The deficiency of documen- tation complicates troubleshooting of the system in the future. Figure 13 depicts the com- parison between the previous system implementation and theoretical best practice for the Support and Rollout stages
Figure 13. Comparison between previous system implementation and theoretical Support and Rollout stages
Figure 13 above shows the activities during the Support and Rollout stage versus theo- retical best practice activities. According to the interviews, Support and Rollout activities were undertaken in the project.
4.4 Summary of key plusses and minuses in previous system implementation
This chapter describes the plusses and minuses of the previous project. This analysis is reflected against the conceptual framework which is presented in section 3.4.
The previous project had pros, but there were many cons also. As section 4.3 illustrated some key activities were forgotten to implement or the skill of running the project was incomplete. No matter what the reason was, the project exceeded both budget and
schedule. The main conclusion, from the company point of view, is that more money was spent than planned. More detailed findings are illustrated in the table below.
Value
Stages
Content Pros Cons
Initiation Strategy KPI
Organizational assets
Business case
Organizational as- sets
Business case
Strategy KPI
Planning Project roles
Management
Integration Plan
Prepare/ Schedule
Document plan
Project roles
Prepare/ Schedule
Management
Integration Plan
Document plan
Execution Environment setup
System integration
Pilot / Testing
System integration
Pilot / Testing
Environment setup
Support/ Rollout Training
System documenta- tion
Support Rollout
Support
Rollout
Training
System documenta- tion
Table 4. Key findings of the project
In the Initiation stage, the project started to skid at the beginning of the project. In the Initiation stage, the lack of defining Strategy and KPI caused many challenges during the system implementation. One challenge was uncertainty to project members. The Project Manager could not keep the focus on the goal, because it was not clear for everyone.
The KPI’s were not defined either. When there were no real indicators for measuring the project, the Project Manager drove the project without a steering wheel and milestones.
The high level planning of the project could not be done properly, because of uncertainty of knowing the current system. Since the project was not aware of what kind of system they are dealing with, deploying integration was difficult and took time. The interviews supported this argument:
“More systematic planning and definition in more detail would have facilitated the implementation of the project. The project started in 2017 and the scheduled deci- sion was during the same year. The real rollout for the project was during 2019.”
Despite the cons, there were two pros in the Initiation stage. One was clear organiza- tional assets. The assets enabled a clear view of resources. As resources were selected, the project manager knew how much can be done in which timeline. Even if there were not enough resources to implement the project on schedule, the project had the technical skills to run the project forward.
The business case had one plus. The business case was understood well, though pres- sure for the implementation came from the system provider. The system integration was
only a matter of time and therefore the company decided to integrate the system as soon as it was possible.
In the Planning stage, the project board made decisions concerning the project roles. In this stage, the pros were for defining project roles and scheduling. The project roles were quite clear, the third parties were drivers and implementers and the IT department, with the company's project managers, were the technical support. As the project was sched- uled in the initial stage, the main challenge for the project group was to keep the project on time. Scheduling the project too early, without an integration plan, causes a challenge of keeping the project on time.
The Management during the project was not present in the traditional way. The manage- ment from the project board had a funding role, but at the same time, it was pressuring the project. The project team was put in a situation where the budget and schedule were determined by the board, but Project Management with the team was responsible for success. This caused an unjust situation for the Project Manager to lead the project as it was agreed with other parties. When asked about the responsibility of the project, the answer was:
“The Project Board didn’t take responsibility for directing the implementation, alt- hough the board defined frames for the project by them selfs.”
Even though the Project board supported the company's project team in negotiations with suppliers.
The Execution stage included System integration and pilot/testing steps. The plusses were system integration. The third parties and IT department had the technical skills to implement integration to the company's system. Testing was made during the integration and it was made successfully. The Execution stage also includes the Environment setup task. In this project, it was not made. The environment setup task was made during the integration. The Setup was not necessary in this case, since the system providers were already aware of the technical details of the system.
The last stage was the Support and Rollout stage. When the project got everything done Support and Rollout were conducted. Support was continuous and was provided by the system providers.
As mentioned earlier, Training wasn’t conducted as it was described in the best practice section. The users participated in the project in the testing period and therefore there was no necessity for it. If users are co-operating with the project, the training task is not crucial. If users are not committed to producing content for the project, training will be one of the most important tasks in the project.
Project documentation was not made during the project. This is a minus in this case project. If documentation is not made properly, the Project group does not have any evidence of what has been done and what not. The project group with the Project board cannot measure the project or learn about it. If this does not cause challenges at the moment, it can cause major money loss in the future. Money loss can be an example of the system fails, troubleshooting of system, or third parties billing regarding changes or fixing the system.
This section illustrated the pros and cons of the earlier system implementation project and it was analyzed reflecting the knowledge to best practice literature. The proposal for the new project will focus on tackling the main cons, which are KPIs, Organizational assets, Business case, Management, Planning the project, Environment setup, and Training and support. Strategy and technical planning such as system documentation, are excluded from the proposal since Strategy is a company higher level plan and system documentation is a more technical task for IT. This analysis gives a firm base for the next chapters, where the proposal is built.
5 Building a CRM implementation plan for Case Company
This section merges the results of the current state analysis and the conceptual frame- work towards the building of the proposal. This section describes how the initial proposal was co-created with the stakeholders of the project.
5.1 Overview of the proposal building stage
In this Data 2 stage, the focus was on building an initial proposal for the CRM implemen- tation plan. The main objective was to create a successful implementation plan for the company. The co-creation workshops aimed to develop the main findings from the cur- rent state analysis by utilizing the conceptual framework built in section 3. Data 2 was collected during sessions with the project team, Project manager, and CDO.
The conceptual framework was built in section 3 based on best practices found in the relevant literature. In section 4, previous system implementation was analyzed by reflect- ing it to section 3 literature. The CSA was conducted by interviewing stakeholders on the previous system implementation.
The initial proposal for an implementation plan for a successful CRM deployment in the case company was created in three workshops with the project stakeholders. The work- shop schedule is shown in table 5 below.
Table 5. Workshop schedule for co-creating implementation plan
Schedule Participants Meeting content
Week 14 2021 CDO, IT manager, Market- ing Manager
CSA and project processes in general level
Week 14 2021 CDO, IT manager, Market- ing Manager
Co-create plan
Week 15 2021 CDO, IT manager, Market- ing Manager
Pilot plan
The first workshop concentrated on the findings of the current state analysis and in gen- eral level four main project processes. The second workshop focused on co-creating the detailed project plan. The third workshop focused on iterating the plan to its final shape.
Figure 14 below illustrates the conceptual framework used as a basis for the focus areas of co-creating the initial proposal.
Figure 14. The focus areas for co-creating the initial proposal
The participants of the meetings included the company’s CDO and IT manager. There were no other participants because the project resources of the company were limited.
The meetings were conducted via Teams conferencing app due to the Covid-19 pan- demic preventing meetings with each other face to face. Between the first and second meetings, the project stakeholders created a personal idea for the plan and based on that proposal plan, the meeting agenda was planned.
5.2 Initiation stage
The initiation stage is the first step of the project. The project should be started with defining KPI’s, project assets and business case for the company. Initiation stage of the
project defines the upperlevel purpose, and meaning of the project. This is usually done by project board with the named project management.
5.2.1 KPI’s
The key element of tracking the project is KPI’s. As the key stakeholder of the project suggested the KPI’s should measure the duration of the task in days, percentage of readiness of task and tasks, and how many days are reserved for a certain task. These elements should be defined in the early stage of the project. When the project knows how much time and resources can be used in a certain time during the project, it reduces under or over resourcing the project in a certain stage. This also allows the project team to push the project implementation in the right direction without worrying about the pro- ject’s internal risks such as organizational assets or resources. When the KPI’s are set and defined, it also provides milestones for the project and warns if the planned schedule or budget is sliding off its course.
5.2.2 Organizational assets
The KPI’s determine the measurement aspect for the project. Organizational assets can be hard money that funds the project, but assets can be also resource assets. In the CRM implementation project, the hard asset was not the known risk. The project man- ager suggested that increasing resources to the project can prevent exceeding the schedule. Without a proper amount of skilled doers, the project will be stuck. The stake- holders of the project agreed with this unanimously.
5.2.3 Business case
A high-level understanding of the importance of the project is one key element of support for the project. As mentioned in section 3, understanding the project worth for the com- pany at every level is important. If users and management do not have a clear under- standing of the purpose of the project, the project can face resistance from users. The project plan suggests focusing on users, management, and project board support during the project. Even if in this case, the business case is understood well, it is always an internal risk, which needs to be followed closely. CRM system implementation is a high-
level investment and it will affect the organization at all levels. As the project manager said:
“CRM will be the key application for the employers and it is understood well among users”
According to the project member, initial feedback from users about the idea to implement a CRM system was positive. This is a good sign for succeeding in the CRM project.
5.3 Planning Stage
The planning stage takes place after the first initial stage. At this point, key components of the project are roles of the project, management, integration plan, preparing and plan- ning, and documentation of the project. These elements build the frames for the project.
This means the project should be planned on many levels. The planning stage is very important, and a well-planned project is key for the successful outcome of the project.
The next sub-chapters describe the elements in more detail.
5.3.1 Project roles
In the beginning of planning, the roles need to be identified at first. This reduces over- lapping work and clarifies the responsibilities during the project. Support for the project should be defined also. In the company, this is usually forgotten and can lead to slowing down the project. The leader of the project should schedule a meeting, where all project participants are attended. The meeting agenda can announce the roles and the respon- sibilities of the upcoming project. This can clear the knowledge of roles for everyone. If the roles are not clear, there might be mixed information during the project and might affect information flow negatively. As the project manager said:
“This kind of project should be established in the right way with the right people.”
In this CRM implementation project, participants have a clear view of the roles.
5.3.2 Management
As mentioned in chapter 3.1.3, management is a key factor of success. As the main project support comes from the project board, the other support comes from the team
