Top Management Support during Large-scale Software Systems Implementations: Important Issues in Management Process

Background/Objectives: Top management support factor is of enormous importance for Large-scale Software Systems (LSS) literature. Method/ Findings: It has been recognized as one of the most commonly observed Critical Success Factor (CSF) element in the successful implementation in the context of Enterprise Resource Planning (ERP) systems. The study is to develop CSF-Live! which is a method for measuring, monitoring, and controlling critical success factors of large-scale software systems? To achieve such goal, we apply CSF-Live for the top management support CSF. The CSF-Live uses the Goal/Question/Metric paradigm (GQM) to yield a flexible framework containing several metrics that we used to develop a formulation, which enables the measurement of the top management support CSF. Application/Improvements: The formulation that we developed for the top management support CSF is crucial to maintain the top management support during LSS.


Introduction
Top management support has a strong impact on ERP implementation success of large-scale software systems 1,2 . Top management support comes through two main factors: • Providing leadership. • Resources necessary (e.g., people, funds and equipment) during the whole ERP implementation process 1 .
Areas of top management support are: 1. Create a suitable environment for the implementation of the project 3 2. Participating in all the processes of the ERP implementation project not just as observers 3 3. Implementation of enterprise resource planning to achieve the desired goals 3 4. Providing financial budget 4 5. Human resource 4 6. Resolution of political problems if necessary 4 7. Good communication with all team members in the project 5 In the case of neglecting any point of the above, this may provide a negative indication of the top management commitment and leadership of project perhaps leading to the loss of staff in company 5 . Some disadvantages of top management practices are: lack of financial support and shortage of experience in the projects 4 . Finally, support, strong and committed leadership at the top management level are essential to the success of the implementation of a large-scale software system 4 .
Current methods evaluate top management support using descriptive measurement, for example high and low. However, no attempts so far to measure this factor using numerical values. In this work, we changed this descriptive method by proposing a new method to quantify the top management support factor. Using this quan-tified measure, we can monitor top management support more accurately.
This paper is organized as follows: in Section 2 presents a short a background, while paper design and methodology is discussed in Section 3. Section 4 shows CSF-Live Method then Section 5 shows measure of top management support. Conclusion is presented in Section 6.

Literature Survey
Large-scale software systems (LSS) are huge and difficult to deal with in all aspects of project management, requirement analysis, design, implementation, testing, and maintenance 6 . Each of these steps needs to be handled separately and differently by competent persons. Enterprise Resource Planning Systems (ERP) is common examples of large-scale software systems. An ERP is a business management software that a company can use to collect, store, manage, and interpret data from many business activities including administrative, functional, financial management, procurement, and warehouses in companies and institutions, as shown in Figure 1 7 .
Several studies and research discussed 8,9 several ERP implementations that have failed or faced serious delays. Several problems and obstacles appeared in the performance of different tasks within the ERPs 10 . It was observed that during such projects there were several factors that led to such results and that gave rise to what is known today as the Critical Success Factors (CSFs) of large-scale software systems. More than 66 critical success factors have been reported in the literature, which were viewed to have an effect on ERP implementations. Further studies have consolidated the long CSF list to a minimum of only 18 factors as shown in Figure 2.
There were no previous attempts to measure these factors which we believe are important to assess the status of each and its subsequent impact on the success or failure of the program. In 11 introduced the Goal/Question/Metric paradigm (GQM) to address measurement of some goal, which maybe an object as well, according to the following approach: • Identification of (a) goal(s) of the project. • Ask questions with respect how the goal can be achieved. • Identify metrics.
GQM consists of three levels:

A. Conceptual level (Goal)
We define a goal for a particular object in a specific environment, using different quality models and for a variety of reasons from various points of view.

B. Operational level (Question)
It is the use of a set of questions to determine the goal of the project and determine the characteristics of the evaluation or accomplish a specific goal.

C. Quantitative level (Metric)
A set of metrics, based on the models, is associated with every question in order to answer it in a measurable way. The Goals is the top of GQM model and it is refined to many questions. Answers of these questions called metrics. The same metric can be the answer for more than one question as shown in Figure 3. Differing viewpoints in answering some of the questions affect the determination of the metrics.
Described the six-step GQM process as follows: i. Establish a set of goals and objectives for the project associated with the measurement of productivity and quality. ii. Ask questions to define those goals clearly. iii. Determine measurements to be collected, which will help you get answers.
iv. Develop data collection methods. v. Collect and validate data on time. vi. Collect and validate data on time.
Measurement goals should be defined in an understandable way and should be clearly structure 12 . The goal is defined by filling in a set of values for the various parameters in the template, it includes purpose (what object and why), perspective (what aspect and who) and the environmental characteristics (where) see more Table 1.

Paper Design and Methodology
To achieve the goals of this article, the following steps were followed which were applied on top management support factor:

Study of critical success factors for large-scale software systems
We present a study of the previous research that focus on the critical success factors for implementing large scale software systems (e.g. ERP systems) and from which we selected top management support factor of these factors to be studied in the framework

Apply GQM-analysis
To measure the impact of the top management support to the success/failure of the project of implementing largescale software system, we used GQM to reach a set of  metrics directly linked to top management support factor to enable monitoring and controlling capabilities.

Measurement Formulation
Using GQM analysis, a formulation of the metric is presented as part of the measurement model for top management support factor.

CSF-Live Method
In this work we used a method (CSF-Live) 13 that represent our proposed framework for measuring top management support factor. The purpose of the CSF-Live method is to measure, track, monitor, and control the critical success factors during the implementation of large-scale software systems by using the Goal/Question/Metric (GQM) paradigm. The CSF-live method has six steps as shown in

Top Management Support as a Numeric Value
Current methods evaluate top management support using descriptive measurement, for example high and low 14 . However, no attempts so far to measure this factor using numerical values. In this work, we changed this descriptive method by proposing a new method to quantify the top management support factor. Using this quantified measure, we can monitor top management support more accurately.
As we see from Table 2, we have formulated a goal to measure top management support from the workshop with the graduate students and some staff at King Abdulaziz University (KAU). We generated a set of ques-tions and metrics during the discussion which helped us to measure the goal. The generation of questions and metrics were driven by the actual formulation of the goal.
In addition, metrics must be represented numerically so that we can quantify the performance of the goal. A formulation of the derived metrics will yield a single number that represents the goal, through which goal achievement can be monitored. It should be noted, that our solution to CSF measurement does show an accurate indication of current status of a single CSF quantified numerically. Figure 5 shows the GQM analysis for top management support (top-down) where level one (top) represents the goal and level two (middle) represents questions and level three (down) contains the metrics. Sometimes, the same question is associated to more than one metric. For example, the question What is the response of the top management from the requests? is associated with two metrics Number of Approved Top Management Support Requests and Number of Rejected Top Management Support Requests. Here for the data collection for the top management support we did not have currently a largescale software system. Consequently, we have created Table 1. GQM goal definition template The object under measurement (process, product, other experience models). Analysis Characterization,evaluation, prediction, motivation, improvement, understanding, controlling, or improving the object.

For the purpose of (Why)
The quality focus of the object that the measurement focuses on (cost, correctness, defect removal, change, reliability and user friendliness….).

With respect to
The people that measure the object (user, customer, manager, developer and corporation….).

From the viewpoint of (Who)
The environment in which measurement tasks place (problem factors, people factors, resource factors and process factors….). In the context of hypothetical data that we assumed to be more relevant to real projects. The following sections explain the details of each metric related to the top management support.
If any metrics are increasing while we implement the large-scale software system, these are positive factors for the top management support (except Number of Change Requests Metric occurs vice versa). Since our work did not coincide in time with a current ERP implementation project we assumed hypothetical values for this and similar met-rics. This data represents 11 weeks such that we measure the value of metrics in each week independently until the 11 th week. We categorized metrics in Figure 5 into two groups, each of which their related metrics are calculated differently.

Number of Meetings / Positive Meetings / Negative Meetings Metrics
The number of meetings / positive meetings / negative meetings metrics are defined as: a numerical count of the meetings / positive meetings / negative meetings while we implement the large-scale software system. By calculating the previous measures on the assumed data that we created, we notice that the meetings held continuously since the beginning of the first week until the last week. Average Daily Meetings (ADM)is an important number that help to measure the meetings levels because it represents average daily meetings since project initiation as shown in Figure 6. Meeting Quality Index (MQI)is another important number that help to compare between the positive and negative meetings because it represents average daily difference between positive and negative meetings since project initiation as shown in Figure 6. By analyzing the number of meetings in over the 11 weeks that we studied, we notice that the largest number of meetings was in the fourth and fifth week (5 meetings in each). As a result, this increased the ADM for the past 4 and 5 weeks to become 0.70 and 0.76, respectively. The smallest number of meetings was in the last week. It was one meeting so decreased the ADM for the past 11 weeks to become 0.65. Often, positive meetings are bigger than or equal the number of negative meetings in each week except in the ninth week where the negative meetings were two while there was only one positive meeting so decreased MQI in this week to be 0.24. However, this was compensated in the tenth week to 0.30 because there were 4 positive meetings and 0 negative metric. Finally, the higher value for the ADM and MQI, the higher good impact on the top management support of large-scale software system and vice versa. Vol 12 (25) | July 2019 | www.indjst.org Wajdi Aljedaibi and Sufian Khamis

Number of Approved/ Rejected Top Management Support Requests Metrics
The number of approved / rejected top management support requests metrics are defined as: a numerical count of the approved / rejected top management support requests while we implement the large-scale software system. By calculating the previous measures on the assumed data that we created, we notice that the approved top management support requests were continuous since the beginning of the first week until the last week. Request Approval Index (RAI)is an important number that help to compare between the approved top management support requests and rejected top management support requests because it represents average daily difference between approved and rejected top management support requests since project initiation as shown in Figure 7. Always, the number of approved top management support requests was bigger than or equal the number of rejected top management support requests in each week. The largest number of RAI was in the second week. It was 0.40 because the number of approved top management support requests were 3 requests while we had zero rejected top management support requests. Finally, the higher value for the RAI, the higher good impact on the top management support of large-scale software system and vice versa.

Number of Change Requests by the BO Metric
The number of change requests by the BO metric is defined as: a numerical count of the change requests by the BO while we implement the large-scale software system. Change requests arise when the top management wants an addition or alteration to the agreed-upon deliverables for a project as additional feature, modifying specification 15,16 . By calculating the previous measures on the assumed data that we created, we notice that the Change Requests Index (CRI) is an important number that help to measure the change requests levels because

Request Approval Index (RAI)
it represents average daily number of change requests by BO since project initiation as shown in Figure 8. We note that the number of change requests by BO appeared since the beginning of the first week until the last week except in the second, sixth and eleventh weeks were there was no change requests by BO. As a result, this decreased CRI in these three weeks to become 0.2, 0.3 and 0.31, respectively. Contrary to this, in the third week the number of change requests by BO was 4. As a result, this increased the CRI to become 0.40 (the highest value in our data). Also, the CRI for the first week was 0.40 as well, because there were two change requests by BO and these change requests were in the first 5 days of the project. Finally, the higher value for the CRI has the higher negative impact on the top management support of large-scale software system and vice versa.

Level of BO Satisfaction Metric
The level of BO satisfaction metric is defined as: a numerical count of the level of BO satisfaction while we implement the large-scale software system. We can measure the level of BO satisfaction weekly by a questionnaire form or an application tool. We can make the value 5 to indicate to an excellent level of BO satisfaction while 0 indicates a very bad level of BO satisfaction. By calculating the previous measures on the assumed data that we created, we notice that the BO Satisfaction Index(BOSI) is an important number that help to measure the level of BO satisfaction because it represents average daily level of BO satisfaction since project initiation as shown in Figure  9. We note the highest level of BO satisfaction was in the second, sixth and eleventh weeks with values 4, 4 and 5, respectively. As a result, this increased BOSI in these three weeks to become 0.7, 0.63 and 0.62, respectively. Also, we notice that the smallest level of BO satisfaction was in the third, eighth and ninth weeks and it was equal 2. As a result, this decreased BOSI to become 0.6, 0.60 and 0.58 respectively. Figure 10 shows bounds of the BOSI so if the BOSI is one or close to one so that will help to the top management support factor to reach in its high level and if BOSI is closer or equal to zero so that will help to that the top management support factor to reach in its low level. We suggest that bad level of BO satisfaction is not a recommended practice and may lead to a decline in the top management support as will be shown later on.

Formulation of Top Management Support (TMS) Metric
We formulated top management support as the summation of ADM, MQI, RAI and BOSI and subtract from this total the CRI that we described in the previous sections shown in following: Table 3 shows important values of metrics that help to measure the top management support and values of the top management support.
We calculate top management support in each week independently until the 11 th week. Based on the results of the hypothetical data that we assumed to be more relevant to real projects, we notice that the ADM and BOSI have the highest influence on the performance of top management support in the new large-scale software system.
In addition, we notice that the values of the top management support changed through 11 th weeks because of the change in some values of the numbers of metrics as shown in Figure 11.
According to the above results, we see that the largest value of top management support was in the second and sixth week: -

Top Management Support = 1.70 in each
Because of the increased values of the MQI, RAI and BOSI in these two weeks, which were in second week example:  While increased the CRI to be: In statistics, there is a technique called normalization, which is adjusting values measured on different scales to a notionally common scale [8]. We applied this normalization on the TMS values to map the minimum and maximum values to the range between 0 and 10. This normalization is described in below:

Zi = ((MAXNUM -MINNUM) * (xi -min(x)) / ( max(x) -min(x)) + MINNUM(2)
Such that max(x) refers to the biggest value while min(x) refers to the smallest value and x i refers to a specific value to be normalized to the range [0-10]. We used normalization of the result top management support between 0 and 10 as shown in Table 3 and Figure  11. We notice the similarity of results of top management support before and after normalization as in Figures 12 and 13. Figure 13 shows bounds of normalization map of top management support so if the top management support is ten or close to ten then it means that the top management support is high and if the top management support is closer to zero then it means that the top management support is low.

Conclusion and Future Works
The complication of the Large-scale Software System (LSS) arises from different factors such as their size, amount of required hardware, lines of source codes, numbers of users, data volume, the diversity of applications and services provided by these systems. In order to achieve a successful implementation of LSS, there are several factors that need to be taken into consideration, which are known as the Critical Success Factors (CSFs) of large-scale software systems. In this work we selected a top management support CSF to be studied by measuring its impact on the implementation of a large-scale software system. We applied CSF-Live! method for measuring and monitoring top management support factor that may affect the implementation of large-scale software. We generated set of metrics which were represented numerically to enable monitoring and controlling of goals and collect data to reflect metrics. Finally, we generated formulas representing top management support factor, collected data, and presented a case study that explores and explains the results. The article that we conducted in this study can be extended in the following way: develop framework for locally developed software: In this study we focused on measuring CSFs for implementation from old to new large-scale systems. Most of these systems are purchased for external vendors. However, few companies prefer to develop their own large-scale software systems. The development and implementation cycle for such systems are different than getting systems from vendors and implementing them. So, we will study in future such kind of in-house developed systems.