Critical Success Factors of System Requirements Definition in IT System Development: An Industrial Case Study

The success of IT system development is largely dependent on the System Requirements Definition (SRD) phase. Researches on Critical Success Factors (CSFs) in the SRD phase are beneficial to the success of IT system development. However, reports that consider the situation in the system requirements definition phase is lacking and these studies try to develop universal truths for CSFs without lessons learnt from empirical evidence need to be characterized. This study is a step towards bridging this gap in characterized evidence to discover “difficult items” in the SRD phase. Moreover, we conducted a case study to justify the importance of CSFs that could be 1) Customer/User Involvement, 2) Clear project goals, and 3) Technical skills of the project team in the SRD phase. The results of the characterization indicated that those major CSFs are consistent. Another issue can also be mitigated by examining Agile method.


Introduction
It is well-known that IT system development success is largely dependent on both the clarity of the ordering side system requirements and on the trustee side skillfulness in making the system requirement definition (Ishii, 2006;Mitani et al., 2008). There are many reports on delay of system development due to extended period of time to complete system requirement definitions (Nikkei, 2013;Nikkei-ITpro, 2012). However, there is no report which analyses the causes of time loss in system requirement definitions. Time losses are thought to be originated from both the ordering side and trustee side. In fact, unclarity of the system requirements at the ordering side is one of the causes of time delay.
Researches on Critical Success Factors (CSFs) in the SRD phase are beneficial to the success of IT system development. The major CSFs of SRD obtained from the interview sessions with engineers who participated in three IT system development through the difficulties (Komai et al., 2016). This case study discusses the challenges that emerged from the issues (problems) and the lessons learnt in System 3 project as shown in Table 1. The goal of this case study is to justify the CSFs of SRD phase in the IT system development project. We identified the following six major difficulties encountered in the interviews (Komai et al. 2016).
1) Insufficient knowledge about the middleware which the ordering side is required to use.
2) Insufficient information about the system requirements from the ordering side 3) Engineers' skills unmatched the SRD phase 4) Difficulty in direct communication with the ordering sides 5) Lack of cooperation with the ordering side 6) Lack of methodology for the current system development Further on, we determined the solutions and CSFs from those major difficulties as shown in Table 2 (Komai et al. 2016).  Customer/User involvement

5)
Lack of cooperation with the ordering side ・To request the ordering side to replace the system. This means more customer cooperation and involvement.
CSF-2: Clear project goals CSF-18: Customer/User involvement 6) Lack of methodology for the current system development.
・To perform engineering, develop the system design and programing concurrently. This means clear Project goal and more customer cooperation and involvement are needed. CSF-2: Clear project goals CSF-18: Customer/User involvement In our research (Komai et al., 2016), CSFs were designed by referring to the CSFs proposed by the papers of Bradley (2008) and Imtiaz (2013) as shown in Table 3. There should be project management planning of welldefined tasks and accurate estimation on required effort (Nah and Lau, 2001). 2 Clear project goals Ding and Wang (2008) noted that the goals are set in accordance with the requirements of the customer (Ding and Wang, 2008). 3 Time budget, manageable workload Reasonable distribution of workload on the staff coordination is very highly artistic work (Fan, 2010). 4 Analysts with both knowledge on business and technology Obtain "business" analysts. One of the critical workforce requirements for the project was the ability to obtain analysts with both "business" and technology knowledge (Sumner, 1999). 5 Technical skills of project team They possess the necessary technical skills and have adequate technology to perform their tasks (Pinto and Slevin, 1987). 6 Selection and management of consultants and staff Reel (1999), noted that building the right team means getting suitable people in the team. Well organized team would be doing better job with good result as the outcome (Reel, 1999). 7 Third parties fill the gaps in expertise and transfer knowledge Howells (2006) referred that actors (third party) fill the gaps in information and knowledge in industrial networks (Howells, 2006). 8 Problem solving with vendors They had IT personnel with knowledge and experience performing better in problem solving than a project group without them (Park et al., 2011). 9 Top management support Fortune and White (2006) referred that this factor can be affected by the general state of the economy; a lack of this factor can lead to project failure (Fortune and White, 2006). 10 Top management is engaged, not just involved Brown et al. identified this CSF is the first of five factors in ERP implementation project (Brown and Vessey, 2003) 11 Management communication, education and expectations Expectations at every level need to be communicated. Management of communication, education and expectations are critical throughout the organization (Nah and Lau, 2001) 12 Establishment of troubleshooting mechanism Troubleshooting is an important independent variable and project success categorized by project phase (Belout and Gauvreau, 2004). 13 Change management hand in hand with project management Brown et al. identified this CSF as the fourth of five factors in ERP implementation project (Brown and Vessey, 2003). 14 Monitoring and feedback against initial plan Adequate monitoring and control is important for the project quality (Fortune and White, 2006). 15 Redesign of business processes Many companies "go to war" with the package and try to make it satisfies their process requirements (Sumner, 1999) . 16 Leadership Many research studies have discussed the importance and/or style of project leadership (Anantatmula, 2008) Leaders should have strong technical and relational skills (McLeod and MacDonell, 2011). 17 Team Work Cross-functional team and cooperation between team members and team work was described as a CSF for IT projects (Biehl, 2007). 18 Customer/User Involvement Park et al. (2011) identified Customer/user involvement in application design is necessary and lack of it can result in IS project failure (Salmeron and Herrero, 2004). 19 Risk Management Fortune and White (2006) also referred that in a successful, projects risk analysis was done at the beginning of the project and risks that arose were handled successfully, whereas in a failed project no risk analysis was done (Fortune and White, 2006). 20 Adequate Requirement Ding and Wang (2008) studied this factor that although it is difficult to gather but it is very important to the success of the system; inadequate requirements usually lead to a failed project (Ding and Wang, 2008).
The following contents after section 1 is structured as follows: Section 2 describes related work, meanwhile Section 3 describes the case study context in which the System 3 project that the author was involved as a project manager. The system development project used in this research was implemented in the actual organization. Because of the obligation to maintain confidentiality of the organization, this case study was conducted based on a condition to generalize and describe the context of the project from the experience of the author. Section 4 discusses the case study design by stating the research questions, data collection, and analysis procedures. The results are then presented in section 5. The challenges and mitigation strategies are discussed based on the author's point of view, and the selection of Agile method to overcome the above identified major difficulties is elaborated.

Related Work
As for the success or failure of IT system development project, there is a study on success factors and success criteria. The Standish Group published its 1994 Chaos report and since then continuously kept publishing the report on the success or failure analysis of the IT project for about 20 years (The Standish Group, 2014). For more than 25 years many researchers have been studying the project success criteria and project success factors including the critical success factors (Agarwal and Rathod, 2006;Emam and Koru, 2008;Müller and Turner, 2007;Wateridge, 1998). Project success criteria refers to dependent variables by which the successful outcome of a project can be judged (Agarwal and Rathod, 2006;Morris, 2000). On the other hand, project success factors refer to independent variables of a project that can be changed in such a way so as to increase the chances of success (Müller and Turner, 2007;Sheikh, 2012;Wateridge, 1998). Müller and Turner (2007) reported that "The importance attached by project managers to project success criteria and the associated rates of project success were assessed for different types of projects, industries and traits of project managers (PM)" in which they received 959 responses from the web-based survey (Müller and Turner, 2007). They conducted the research to respectively set the independent variables such as Project types, Sectors, and PM Traits, and dependent variables such as the importance attached to different project success criteria as fixed by the project manager. Their finding is that the performance of the project is against various success criteria claimed by the project manager. Although their research was not specified for the ICT industry, they reported that ICT and organizational change projects are ranked significantly higher in the overall success rate compared to engineering projects and other Project type, among high-performance projects. The authors remarked that this result might be addressed in further researches. It can be said that it is very difficult to prove the relations between a project success factor and a project success standard from these research findings.
According to Critical Success Factors in IT fields, there are many researches for Critical Success Factors (CSFs) in IT fields. About the IT system development, the 1994 Standish CHAOS Report illustrated that top 10 factors found in successful projects are as listed in table 4 (The Standish Group, 2014). These results reflect the consensus on the latest IT system development. In particular, it is interesting that the percentage below the fourth place is quite low, ranging from 1st to 3rd. In addition, although customer participation in the project is ranked at the 1st place, this is a factor that is deeply involved in the system requirements definition phase. It is inferred that a definite third item: Clear Statement of Requirements is chosen as its relation. These two factors indicate high responsibility of the system's ordering side.
As an example, Poon and Wagner (2001) called CSFs as the conditions that need to be met to assure success of the system (Poon and Wagner, 2001). Fortune and White (2006), explained that "where project management is concerned, the search for CSFs began in 1960s. Since then many authors have published lists of factors, sometimes relating them to specific problem domains and types of activity, sometimes stressing their applicability to all types of projects and sometimes turning the notion on its head and instead prefer the critical failure factors" (Fortune and White, 2006). Fortune and White (2006), reviewed 63 publications that placed an emphasis on CSFs and those CSFs were mapped onto components of the Formal System Model (FSM). They identified 27 CSFs from their literature review and mapped onto components of the FSM. However, Clear Statement of Requirements which is the third item on CHAOS report is not in their CSFs. Nasir and Sahibuddin (2011) highlighted comprehensive study reporting on different project sizes in various domains and in multiple countries (Nasir and Sahibuddin, 2011). They identified forty-three articles from the years 1990 to 2010 which could be analyzed to develop a list of critical factors that specifically affect the success of software projects. They suggested that organization or project manager is attentive to control the top five critical factors to drive projects towards success since the frequency of occurrences' percentages for each is greater than 50%. They found that the factors such as clear and frozen requirements, realistic estimation of the schedule and budget, along with a competent project manager are the five most critical success factors for software projects. They found 26 SCFs and compared to CSFs found by Fortune and White (2006) with their frequency of expression. Nasir and Sahibuddin (2011), discovered that Clear requirements and specifications as the first CSF and Frozen requirement as the tenth CSF in their study. Those two CSFs are of major difference with Fortune and White (2006).
Our study defined 20 CSFs which were designed by referring to the CSFs proposed by the papers whose authors are Bradley (2008) and Imtiaz (2013) as shown in Table 3 (Komai et al., 2016). Imtiaz (2013) described that it is "the most necessary components for success in software development projects, executive information systems etc." (Imtiaz, 2013). Bradley (2008) referred to a paper by Bullen and Rockart (1981) which defined critical success factors (CSFs) in IS as "the few key areas of activity in which favorable results are absolutely necessary for a particular manager to reach his goals" (Bradley, 2008). These CSFs in his study was applied to classic management framework from the literature review. He then derived his research model from these CSFs and attempted validation from eight ERP implementation cases. We decided to advance our study by referring to CSFs in his study, because the recent system development is being shifted to a development project assuming it is for the implementation of middleware and ERP.
We define the CSFs as the element which refers to specific activities, procedures, or areas that enterprise or organization depends on for its continued survival. CSFs are unique to each organization and will reflect the current business and future goals.

Case Study Context
The subject of case studies dealt with in this section is System 3. System 3 should include requirements for relatively small-sized System 1 and medium-sized System 2 as shown in Table 1. Also, it is reasonable to visualize that System 3 is a large-scale system that was the most difficult and that the author was a project manager of three system development. Given the author's context makes it harder to generalize research answers, tasks, and lessons, it is however, crucial enough to present information on the project organization and stakeholders.

The Project Organization
System 3 handled here is a failed project that had a delivery date and quality but had a problem with cost. The System is one of the IT system development projects for a mid-sized system integrator (MSI) with 1000 employees. As shown in Table 1: Targeted three system characteristics, System 3 is larger than other systems with the number of functions to be realized, degree of the processing function complexity, mutual dependence between the processing functions, number of user interface screens, number of user input items, and processing function change corresponding to the user inputs. Furthermore, the system development scale was 566 man-months compared with System 1 for 21 man-months and System 2 for 63 man-months.
The internal project organization chart of System 3 is as shown in Figure 1. From the customer's point of view, there are a customer's information system subsidiary (ISS), a computer vendor, and our organization comes under that. This figure is an organization chart as of March 13, 2009 about one and a half months after the author was assigned as the project manager (PM). There was a system to develop the projects ordered by the sales consultant division in the engineering department. Under PM there are engineering leader and PMO (Project Management Office) leader. There are 10 personnel under the engineering leader and 6 persons under the PMO leader, thus there are total of 20 persons including the department manager.
The main role of PM is managing project quality, cost, and delivery date. We identified the tasks necessary for the project on a weekly basis by collaborating with engineering leaders and PMO leaders, then reviewed the results of last week. The characteristic of this organization is that three persons who describe requirement definitions are placed in PMO, accompanying staff members and customers are under the engineering leader, gather the information obtained and take it back to the requirement definition document. This is because the project had started in October 2008 and the end time of the requirement definition phase negotiated with the customer was January 2009, but since there was only a memorandum of artifacts, it was an organization devised as a recovery measure. In addition, it was an organization necessity to prepare for an increase of staff after April.

The Project Stakeholders
This section lists the stakeholders and their roles related to the project. The representative of the customer side is Mr. I. He attended general meetings held to discuss serious aspects of the project. These meetings were preestablished and were in forms of conferences for taking his final approval. There is a division that uses the customer's system under his command, and many requests for system requirements came from there. Originally, the person in charge at the customer's Information System Subsidiary (ISS) listed below had to organize their requirements and describe the requirement's definition. The representatives of the customer's information system subsidiary (ISS) are Mr. O and Mr. N. They are primarily responsible for eliciting, analyzing, specifying customer requirements, and verifying customers' contents. However, since the number of persons in IT subsidiary is relatively small compared to the system scale, the system integrator has become an organizational structure that arranges and formats the placement of those requirements. There is a computer vendor involved in this task. Representatives of the computer vendor are four persons namely Mr. O, Mr. W, Mr. M, and Mr. H. There was our project organization under this computer vendor. Koichi Suzaki (Director) at the top of Sales Consultant Division in our project organization, Mr. K, Mr. A, Mr. Y (Sales Coordinator) under that subordinate; they received a system from computer vendors, then internal orders were given to the internal engineering department. The organization of the internal project organization is as described in the previous section.

Case Study Design
This case study was conducted using a qualitative research approach, which is appropriate when individual perceptions of a complex phenomenon in its context is to be studied. However, it is also used for descriptive purposes, if the generality of the situation or phenomenon is of secondary importance. Case studies may be used for explanatory purposes, e.g. in interrupted time series design (pre-and post-event studies) although the isolation of factors may be a problem (Runeson and Höst, 2009). This case study will proceed based on the general process defined in Runeson and Höst (2009) as shown in Figure 2. The first step is to determine the goals of the case study and to plan the procedure. The second step is to prepare and collect the data. The third step is to analyze the collected data and describe the result. Finally, the fourth step takes the result obtained from these processes into consideration for analysis.

Research Questions
As previously explained, the main objective of this case study is to justify the CSFs of SRD in IT system development obtained in System 3.
Thus, to characterize these difficulties, we defined the following research questions: 1) How does the project manager characterize the "Insufficient knowledge about the middleware which the ordering side is required to use"?
This question aims to identify the issues regarding the use of middleware. Middleware is ERP (Enterprise Resource Planning) and business package software such as financial, personnel, sales marketing, call center, customer relationship management, etc. Middleware is the core of software artificial in IT system development these days. As a result, the answer for this question can lead to the possible solutions and CSFs which are determined as per Table 2.
Possible solutions; ・To add engineers with sufficient knowledge ・To assign the third-party engineers filling the knowledge gap about the middleware. ・To conduct training in fulfilling the knowledge CSFs; CSF-5: Technical skills of project team CSF-7: Third parties fill the gaps in expertise and transfer knowledge CSF-11: Management communication, education, and expectations 2) How does the project manager characterize the "Insufficient information about the system requirements from the ordering side"?
This question aims to identify the main issues on how requirements are not elicited. Characterizing on why elicitation of requirements from the customers had failed. As a result, the answer for this question can serve as the possible solutions and CSFs which are determined in Table 2.
Possible solutions; ・To request for determination of the additional staff requirement ・To request for customer to be more involved ・To ask the System Integrator partner to jointly get the ordering side requirements CSFs; CSF-2: Clear project goals CSF-18: Customer/User involvement 3) How does the project manager characterize the "Engineer skills unmatched the SRD phase"? There are lots of definitions for skills such as management, communication, leadership, technology and so on. In this case study, the project organization used to define the IT skills level, similar to IT skills standard (Komai 2007). This question aims to explain why the engineering skills unmatched in the SRD phase occurs. As a result, the answer for this question can serve as the possible solutions and CSFs which are determined in Table 2. Possible solutions; ・To provide engineers with sufficient knowledge ・To assign the third-party engineers bridging the knowledge gap about the middleware ・To conduct training that can fulfill the required knowledge CSFs; CSF-5: Technical skills of project team CSF-7: Third parties bridge the gaps in expertise and transfer knowledge CSF-11: Management communication, education and expectations 4) How does the project manager characterize the "Difficulty in direct communication with the ordering sides"? As shown in Figure 1 Project Organization of System 3, there are customer information system subsidiaries and computer vendors between the customer and project organization. This question aims to visualize how difficult to have a direct communication with the ordering sides. As a result, the answer for this question can serve as the possible solutions and CSFs which are determined in Table 2. Possible solutions; ・To have direct communication with the ordering side. This means that more customer is involved directly CSFs; CSF-18: Customer/User involvement 5) How does the project manager characterize "Lack of cooperation with the ordering side"? When the project began in October 2008, the goal of the new system was to replace the old system tasks delivered by IBM with the latest infrastructure provided by Genesys. It was the goal that the information is the subsidiary of the customer's thought. However, new requirements have come out from end users while the requirement definition is progressing. This question reveals what lack of cooperation on the ordering side made the definition of the requirement becomes difficult. As a result, the answer for this question can serve as the possible solutions and CSFs which are determined in Table 2. Possible solutions; ・To request the ordering side to replace the system. This means more customer cooperation and involvement CSFs; CSF-2: Clear project goals CSF-18: Customer/User involvement 6) How does the project manager characterize the "Lack of methodology for the current system development"? All the development methods of the three IT systems handled in this research adopted Waterfall method. System 3 was poor in contents as described in the requirement definition document compared with the other two systems. Experience has shown that the volume ratio of the requirement definition document to the basic system design document can be in the range of 1 vs 3 to 1 vs 4 (Komai et al., 2011). The requirements definition as a product was 150 pages, but the basic system design document was 1,200 pages. As a result, ratio is 1 vs 8. This is because the description on important call flow and its control procedures in the call center's system is in the system basic design document and not in the requirement definition document. Those call flow and its control procedures were new functions required from customer user side. However, System 3 worked because planned due date and quality were already secured. However, cost related issue was still a problem. This question aims to present another approach, such as Agile method, which is the new development method than Waterfall. As a result, the answer for this question can lead to the possible solutions and CSFs which are determined in Table 2. Possible solutions; ・To perform engineering, developing the system design and programming concurrently CSFs; CSF-2: Clear project goals CSF-18: Customer/User involvement

Data Collection Procedures
This study adopted two data collection methods, namely documentation analysis and interviews analysis. The interviews were done in our research (Komai et al., 2016).

Documentation Analysis
Documentation analysis is a technique which focuses on the documentation to understand the project (Seaman 2008). The documentations are recorded in a notebook diary and a typical notebook which were written by project manager during system 3 project execution. Another documentation is organization chart which was already described in Figure 1: Project Organization of System 3. There is also System 3's Damage insurance company ICC Project Raw data in appendix C. As a reference, there is a man-hour table of System 3 which was recorded by project manager and will be presented later.
In the notebook diary written by Japanese, there were records on what kind of task, when it started and ended, and the related task which were executed by the project manager in 2009 as in the photograph shown Figure 3. Notes on this notebook diary was taken in 2009. When you open this notebook, you can describe the schedule and achievements for one week on the left side, and it is designed so that you can write your notes freely on the right side. This notebook diary was one-year record for 2009.

Figure-3. Example of notebook diary in 2009 in Japanese
Another notebook written by Japanese describes important salient points during formal meetings and face to face meetings with project team members. For example, there was a formal meeting with computer vendor on 26 th February 2009. In the notes, there are 600 call flows and 60 patterns, and it was stated that the customer shall confirm this content. This notebook has 60 pages, 6mm x 35 line in page, and was records were written between January 2009 and April 2009. Many things can be captured through this method such as insufficient knowledge about the middleware which the ordering side is required to use, insufficient information about the system requirements from the ordering side, and engineer skills unmatched the SRD phase.

Analysis From Interviews
Face to face interviews of System 3 were conducted in our research (Komai et al., 2016). There were also answers, and solutions gathered from the interviewees. From this method, difficulties faced were captured in terms of direct communication and lack of cooperation with the ordering side, as well as lack of methodology for the current system development.

Analysis Procedure
Based on Yin (2009) and Runeson and Höst (2009) these researchers analyzed the collected data qualitatively, and the overall analysis procedure is shown in Figure 5  The data analysis in this section was guided by the grounded theory method found in social justice research as according to Charmaz (2017). In this method, the data is constantly compared to the previous data, until a saturation point is reached, where new sources of data do not lead to any change. After data collection, we concentrate on data interpretation in a comprehensible format by writing simple description based on the research goal. Those explanations were categorized as per Table 5 considering the interest from research questions. This table consists of major difficult items, source of data, and data descriptions.
The conclusion task in figure 5 is responsible for data interpretation either through explanations or quoting from some other references. Discussions with supervisors related to this research were performed to test, verify, and validate the conclusions. For each data collection instrument, these steps were considered in making draft characterizations on our insights and advised the suggestions related to each research question. Interview ・When it started in October 2008, the system design document delivered by IBM was handed over from the ISS (Information System Subsidiary) person in charge with instruction "Please make it according to this design document". ・Customer, ISS, computer vendor and our project team agreed that call center applications compiled the document by computer vendor side, and our project team were mainly to build networks and Genesys Middleware's call center infrastructure. ・However, when we had an appointment with ISS, they said "It is as written in the system design document delivered by IBM. We are paying money, so please bring a good suggestion" and it had become a conversation. Engineer skills unmatched the SRD phase Notebook Notebook Notebook Notebook and Interview Notebook Notebook ・These engineers were good at programming, but had insufficient skills to elicit requirements from users, analyze their contents and verify them. ・Also, it is necessary to understand SIP (Session Initiation Protocol) server and discuss with customers. ・So, the project team hired external experts from the end of March to the end of April to complete this work. ・Three regular employees participated in this project through organizational change, and the project organization workforce was strengthen. ・Ten external engineers with middleware knowledge were subordinated to these three persons, and full-scale recovery work had started. ・These personnel formed substantial OJT (On the Job Training), a team with the past project staff and tasks was assigned. Difficulty in direct communication

Notebook and Interview Notebook
・After the interview with customer, the reply is notified to us via the person in charge of the ISS, and computer vendor. It took two to four with the ordering sides weeks from the interview to receive the reply. ・The ISS side have three persons in charge, six people from computer vendors, and fifty people from our project team.

Case Study Results
In this section, the findings of this case study are presented describing the difficulties and solutions within the System 3 project organization, through the answers to research questions.

RQ1:
How does the project manager characterize the "Insufficient knowledge about the middleware which the ordering side is required to use"? The goal of system 3 project was to build a system that integrates several call centers in the IP (internet Protocol) network. Because IP-based call center systems integrate voice and data communication infrastructure with IP, hence you do not have to worry about distance or talk time cost like conventional telephone service. Therefore, it is possible to drastically reduce the communication cost and to integrate the internal network.
At the beginning of the project between Oct 2008 and Jan 2009, there were two engineers to identify the SRD in our project team, but they were soft phone engineers. Soft phone runs in client desk top PC which each user (call center agent) uses. It has a new feature where it is connected to PBX (Private Branch Exchange) compared to hard telephone. They did not have knowledge about the middleware. Moreover, the customer, staffs of customer information system subsidiary, and computer vendor's project team members did not have knowledge about middleware.
After the team had assigned the project manager, they also had appointed three new engineers who are specialists in middleware from outside company in Mar 2009 as shown in Fig 1 Project Organization. These three engineers were specialists who procured from a development company of call center related to middleware (Manolopoulos, 2006). They contributed as project members for one and a half year until this project had converged in October 2010. Thus, the possible solutions are, for example, to add engineers with sufficient knowledge and to assign third-party engineers to fill the knowledge gap about middleware. Then CSF-5: Technical skills of project team and CSF-7: Third parties were selected to fill the gaps in expertise and for knowledge transfer (Bjarnason et al., 2011;Brown and Vessey, 2003).
The project organization also sent five trainees of internal new project members to the product technology workshops held by middleware vendors for 15 days during the period from Feb to Mar 2009. In-house engineers who received these trainings worked as the main staff at the developing stage in the in-house test system and had carried out prototype development from around July 2009 when the requirement definitions were completed. Because of these reasons the possible solutions were to conduct training to fulfill the knowledge, and CSF-11: Management communication, education and expectations was selected (Nah and Lau, 2001).
The other action the project team had taken was having a consulting support contract by technical engineer of middleware vendor. The knowledge about middleware is required not only for middleware specification but also for application and proposal to business utilizing the middleware. Engineers of middleware vendors were familiar with the specification of the products, but those were outside the scope of their application and their application to business.
Regarding vendor support, it was not effective for the process of eliciting the requirement on the business system and specifying it. Therefore, CSF -8: Problem solving with vendors was excluded.
On the other hand, to develop soft phone, it is necessary to understand SIP (Session Initiation Protocol) server and communicate with customers. This item is done by borrowing from external experts and is discussed in section 5.3.

Insufficient Information About the System Requirements From the Ordering Side
The System 3 project was to rebuild PBX based call center system built by IBM on IP based integrated infrastructure. When it was started in October 2008, the system design document delivered by IBM was handed over from the person in charge of ISS (Information System Subsidiary) and instructed "Please make it according to this design document". Customer, ISS, computer vendor and our project team agreed that call center applications were compiled by the computer vendor side, and our project team was mainly to build networks and Genesys Middleware's call center infrastructure. However, when we make an appointment with ISS, they said that "It is as written in the system design document delivered by IBM. We are paying money, so please bring a good suggestion" and it has become a conversation. Ultimately, as of March 2009 when the structure of Figure 1 Project Organization of System 3 was in place, the requirements definition of the infrastructure was almost completed. However, applications such as call center flow were undefined. As an adequate solution, we should ask the customer to increase staff here and proceed with the requirement definition (Lee and Kim, 2007). Thus CSF-2: Clear project goals and CSF-18: Customer/User involvement are considered (Sudhakar, 2012). It is also nominated CSF-20: Adequate Requirement. As for this CSF, Ding and Wang (2008) studied this factor that although it is difficult to gather, it is very important for the success of the system; inadequate requirements usually lead to a failed project. (Ding and Wang, 2008). As the solution to this difficulty, our project team had shifted key staff to the basic system design phase since April 2009. The requirement elicited by that work was described in the PMO (Project Management Office) requirement definition staffs.

Engineer Skills Unmatched the SRD Phase
Regarding unmatched technical skills in the SRD phase, it was described in section 5.1 that there was a concern with employment of Softphone engineers. These engineers were good at programming, but insufficient skills to elicit requirements from users, analyze their contents and verify them (Biesalski and Abecker, 2008). Also, it is necessary to understand SIP (Session Initiation Protocol) server and communicate with customers. So, the project team hired external experts from the end of March to the end of April to complete this work. Thus, the possible solutions are; to increase engineers with sufficient knowledge and to assign third-party engineers filling the knowledge gap about the middleware. Then CSF-5: Technical skills of project team and CSF-7: Third parties fill the gaps in expertise and knowledge transfer were selected (Fortune and White, 2006).
A Japanese company had implemented a large personnel change on April 1. Three regular employees participated in this project through organizational change, and the project organization was strengthened. Ten external engineers with middleware knowledge were subordinated to these three persons, and full-scale recovery work had started. These personnel formed substantial OJT (On the Job Training), a team with the past project staff and tasks were assigned (Tabassi and Bakar, 2009). Thus, the possible solutions are to appoint engineers with sufficient knowledge, to assign the third-party engineers filling the knowledge gap about the middleware, and conduct trainings to fulfill the knowledge. Then CSF-5: Technical skills of project team, CSF-7: Third parties fill the gaps in expertise and knowledge transfers as well as CSF-11: Management communication, education and expectations were selected (Fortune and White, 2006).

Difficulty in Direct Communication With the Ordering Sides
As shown Figure 1 Project Organization of System 3, there are two companies between customer and our project organization. A formal regular update meeting was held with the person responsible for the ISS (Information System Subsidiary) once a week. The schedule was adjusted after preparing the discussion subject and the solutions prior to the customer interview. After the interview, the reply was notified to us via ISS person in charge, and computer vendor. It took two to four weeks from the interview for them to respond with answer. It is the ISS person in charge who mainly talks with the customer, ISS staffs seemed to be busy and always occupied. As though, they seemed to have other tasks to do on a daily basis. There were three thousand agents at the customers' call centers, at 4 sites, and they were roughly divided into six departments. On the other hand, the ISS side had three persons in charge, six people from computer vendors, and about fifty people in our project. The bottleneck of the requirement definition was with the person in charge of the ISS (Liu, 2011). Originally, they should define the requirements. Thus, the possible solution is to have a direct communication with the ordering side. This meant more customer involvement is directly required. And required CSF is CSF-18: Customer/User involvement (Verner, 2005).

Lack of Cooperation With the Ordering Side
As described in section 5.2, the person in charge of ISS (Information System Subsidiary) instructed "Please make it according to this design document" at the beginning of this project in October 2008. The system design document was delivered by IBM. Moreover, Customer, ISS, computer vendor and our project team were in agreement that call center applications were compiled by the computer vendor side, and our project team was mainly to build networks and Genesys Middleware's call center infrastructure. However, when we had an appointment with ISS, they said "It is as written in the system design document delivered by IBM. Engineering leader said that ISS person asked him "We are paying money, so please make a good suggestion" at the beginning of the requirement definition.
These situations had continued until around May 2009 when project comprehensive recovery had commenced. In May, we proposed to build a prototype model that runs on middleware from the functions that the basic design had completed. This proposal was accepted in the middle of June, and thereafter continuous function design and development were carried out until mid-September. During this period, the goal was to build a new infrastructure according to IBM's system design document, which was the original goal, but was rebounded. Customers continued to make requests that they wanted to improve and we were caught up with the feedback response every day (McLeod and MacDonell, 2011). Thus, adequate solution is to request the ordering side to replace the system. This meant more customer cooperation and involvement. And required CSFs are; CSF-2: Clear project goals and CSF-18: Customer/User involvement (Sudhakar, 2012;Verner, 2005).

Lack of Methodology for the Current System Development
This difficulty has a different meaning from the above five items. This is because the above five items are mainly caused by the resources of the project and its allocation, and the problems can relatively be identified. If the project resources are insufficient, costs need to be considered, but we can hire external experts to deal with those difficulties. In section 5.2, the project team shifted its staff to the basic system design phase while examining applications such as call center flow since April 2009.
In section 5.5, we proposed to build a prototype model that runs on middleware in the order of the basic design completed functions in May 2009. Butler and Fitzgerald (1999) describe the use of prototype had increased the level of user participation and involvement in the projects by providing a common language (Butler and Fitzgerald, 1999). It was this paper, that bridged the traditional gap between technically-oriented developers and business-oriented users (McLeod and MacDonell, 2011). Thereafter continuous function design, development, and validation were carried out until mid-September 2009. As a result, after October 2009 the acceptance test on the customer side system was implemented. In November 2009, we carried out the integration test within the actual operation environment, and in February 2010 we could start the actual operation. Ultimately, although this project secured the delivery date and quality, it was evaluated as a costly failure project. The method in this section is to resolve the cost issue. How can we optimize the cost, the man-hour on IT system development? The challenge to this task is made by some breakthrough. There is a hint in building the prototype model used in Section 5.5, and continuous design and development of functions involving customers. Thus, the possible solution is to concurrently perform engineering, develop the system design and programming. And required CSFs are CSF-2: Clear project goals and CSF-18: Customer/User involvement.

Main Finding and Discussion
In this case study, some general findings were elicited. The first thing we can say is that the CSFs for the major difficulties gained from the interview are consistent. Second, from the results obtained, the relationship between the major difficulties and CSFs on the above explanation is schematized as shown in the figure 6 (Lehtinen, 2014).
In group 1, engineer skills unmatched the SRD phase is related to insufficient knowledge on the middleware. This group had problems with resources in the project organization. By securing adequate personnel, the project had entered a comprehensive recovery phase.
In group 2, difficulty faced in direct communication with the ordering sides is related to insufficient information about the system requirements and lack of cooperation with the ordering side. This group had problems with customers outside of the project organization or in the middle of the integrator (computer vendor). One reason is the structural problem in the software industry (Minetaki and Motohashi, 2007). An empirical analysis on industry structure and productivity of Japan's software industry was described. According to the report, Japan's IT industry has low industrial productivity as it is more towards software than hardware. Small and medium-sized IT service companies form multilayered outsourcing structures under large enterprises. It has classified software companies in either "an original contractor", the "middle subcontract" or "last subcontract". By comparing the productivity level, "a middle subcontract" was at the lowest. This report is the evidence for difficulty faced in direct communication with the ordering sides, because of multilayered company's structure as shown Figure 1. Another report made comparison within the IT human resources in seven countries such as USA, China, India, Vietnam, Korea, Russia, and Japan (Information-technology Promotion Agency Japan, 2011). We calculate the population number of user enterprise IT engineers per one million people and the population number of IT service enterprise IT engineers per one million people according to each country's population in 2011 as shown Figure 7.

Figure-7. IT human resources comparison in seven countries
This graph indicates that USA has more than triple number of IT engineers in user side than Japan. On the other hand, Japan has twice IT engineers in IT service side than USA. This number means the shortage of IT technicians on the user side in Japan. As described in section 5.4, there were three thousand agents at the customers' call centers, at 4 sites, and they were roughly divided into six departments. On the other hand, the ISS side had three persons in charge, six people in computer vendor's side, and in our project was about fifty people. The bottleneck of the requirement definition was with the person in charge at ISS. From the beginning, they should define the requirements. Based on these results, it would be impossible to successfully terminate the requirement definition, besides improving the quantity and quality of IT personnel on the customer side.

Approach to Agile Method
This section clarifies the issue from section 5.6 which is lack of methodology for the current system development. As described in section 5.6, the requirement definition as the deliverable of this project was delivered in October 2009 with call flow undefined. After all, the system cut over in February 2010 without the required definition of the most important call flow. Ultimately, although this project secured the delivery date and quality, it was evaluated as a costly failed project. From graph in Figure 8, the project's recovery plan had started since January 2009. The project's peak timing was in August 2009. There were continuous function design and development process in building prototype from June to August 2009. These processes are similar to Agile method. But we were not concerned of Agile at that time. Figure 9 shows cumulative curve of mon-month for system 3. What we can see from this graph is that the SRD converged in May 2009. The BSD (Basic System Design) and SPD (Specification Design) almost converged in October 2009. But, PRG (Programming) and TST (Test) are increasing until the start of real operation in February 2010. It can be said that there were lot of re-work occurred during October 2009 to February 2010. It is thought that these re-works were the root cause for the cost overruns. In principle, System 3 has been developed according to Waterfall method. As for future research, we would like to make a comparison in man-hours using Agile method as a theme.

Conclusion and Future Work
IT system development success is largely dependent on both the clarity of the ordering side system requirements and on the trustee side skillfulness in making the system requirement definition (SRD). In order to address these issues, researches on Critical Success Factors (CSFs) in the SRD phase are essential to the IT system development success.
This case study aimed to justify the CSFs of SRD phase in the IT system development project which were identified as major difficulties from the interviews (Komai et al., 2016). We discussed and justified the CSFs and those solutions in SRD under six difficulties: 1) Insufficient knowledge about the middleware which the ordering side is required to use, 2) Insufficient information about the system requirements from the ordering side, 3) Engineer skills unmatched the SRD phase, 4) Difficulty in direct communication with the ordering sides, 5) Lack of cooperation with the ordering side, and 6) Lack of methodology for the current system development. In this case study, we can say that the CSFs for the major difficulties gained from the interview are consistent.
Moreover, we classified those difficulties into three groups. The first group consists of two difficulties that 1) Engineer skills unmatched the SRD phase related 2) Insufficient knowledge about the middleware which the ordering side is required to use. The difficulty faced by this group was a problem for human resources inside the project and it was resolved after appropriate resources were provided.
The second group comprises three difficulties that 1) Difficulty in direct communication with the ordering sides related 2) Insufficient information about the system requirements and 3) Lack of cooperation with the ordering side. There were two social issues for difficulties with this group. One reason is the structural problem of the software industry (Minetaki and Motohashi, 2007). This report is the evidence for difficulty in direct communication with the ordering sides, because of multilayered company's structure as shown Figure 1. Another reason considered is the number of IT engineers in customer side. Based on the comparison of IT engineers in customer side between Japanese and USA in Figure 7, customer should have more IT staffs to successfully terminate the requirement definition.
The third group presented independent issue about IT development method. The success of IT system development simply depends on good requirements definition and fast, cheap, and good quality software development. This case was considered as a failure project due to cost as per the evidence in Figure 9. There were lots of re-work done in prototype development. In principle, System 3 was developed based on Waterfall method. As for a future research, we would like to compare the man-hours with Agile method as a theme.