1. INTRODUCTION
Cross-functional systems and infrastructure systems used by enterprise systems or multiple departments integrate information for use by various stakeholders within an organization [1]. The development or implementation of these large-scale projects is generally supervised by top management,along with the central information technology (IT) department. Alongside these overarching projects, the number of systems in user departments or functional areas has also been increasing rapidly in recent years. These systems are underpinned by a stream of IT consumerization, which is a sign of how emerging new IT has spread within organizations. Escalating IT expenses that include personal mobile devices as well as a variety of other software services, are forcing businesses to reconsider the acquisition and management of IT equipment and services. In this change, which involves Bottom-Up Information Systems (BUIS), the central IT department and top management focus only on the actual systems required for control management. Many modern enterprises are adopting this concept of BUIS management [1], [2].
However, BUIS projects are often accompanied by their own set of challenges. In the case of domestic banking in South Korea, for example, the launch of several applications (apps) in recent years has resulted in customer confusion. It is also the reason many users have stopped using these apps, as they are considered a waste of time. Additionally, often, it is not until after the launch of the app that it becomes evident it is confusing to manage, requiring a reduction in the number of apps or the integration of the app with already-existing apps offered by the same company [3], [4]. As of January 2017, there were 77 apps launched by four major commercial banks (Kookmin, Shinhan, Woori, Hanah), with 29 apps for Shinhan Bank alone [3]. One reason for this large number is that many of these banks have competitively launched apps to enhance their mobile services in various segments of the banking world (smart finance, customer wealth management, etc.).
The difficulty of managing a variety of up-and-down information system projects, such as the banking case described above, is primarily owing to the differences in the characteristics of BUIS projects compared with traditional top-down system development projects. The main differences include the size of the project, the development period, the departments responsible, and the role of the internal IT department. BUIS projects are smaller and more limited in scope than top-down projects. The development period is also relatively short. Often, it is the user department that is responsible for managing the project, rather than the internal IT department. The role of internal IT is often marginal during the project process; it intervenes only after the project is complete.
Given these characteristics, BUIS projects face challenges not only in terms of general project objectives such as schedules and budgets, but also in how the systems that are finally developed are integrated and harmonized within the organization. Control is a tool that organizational managers can effectively use to address such challenges [5], [6]. Here, control includes all attempts to ensure that individuals behave in ways that meet collective goals [7]. Previous research has examined the control of various types of IS projects, including in-house, custom developed, packaged software, outsourced, open source, and cyber infrastructure [8, 9, 10, 11]. Existing literature suggests that both single control modes, as well as a portfolio of various control mechanisms are used to manage complex IS projects [6], [12]. Collectively, these studies provide important findings and insights into formal and informal control, especially those exercised by IT departments and those employed in top-down information systems projects that have user participation.
BUIS projects constitute a unique type of system development, which differs from the traditional approach in which the IT department plays a leading role and the user department plays a supporting role after the project ends. Therefore, it is difficult to apply any previous research results to the control of BUIS projects. These projects may require new forms of control not covered in the existing literature [2], as most BUIS projects concern the development of small and new varieties of information systems, rather than large-scale development of information systems, which have been dealt with in the past. Therefore, the control challenges posed by BUIS projects are significantly different from those studied by previous research, and require a fundamentally new management control method. In this study, our aim is to bridge the gap between these studies and present new research directions on the relationship between BUIS project control and outcomes (such as project performance, system performance, organizational performance, etc.). This study explores the control of BUIS projects, a topic that has not been addressed in existing studies; therefore, we can expect the application of control in a new context.
2. LITERATURE REVIEW
2.1 BUIS Projects Characteristics Differentiated from Top-Down IS Projects
BUIS projects differ in many respects from top-down projects, the traditional system development method. Among the main differences, the difference in project size is first. Cross-functional systems used by enterprises’ infrastructure systems, enterprise systems, and various departments are project-sized and supervised by top management along with central IT departments. By contrast, BUIS projects have relatively small project sizes and budgets. In addition, these projects are often developed by the respective user department in response to specific information requests or needs that are not satisfied by the system currently in use [13]. For example, a university hospital in New Zealand is already using a paging system that can call physicians urgently; however, as it is also used by other hospital users (e.g., doctors), another paging system is being tested and introduced [2]. In another case, a foreign university has been using the Blackboard system in the department of lifelong learning or executive MBA. Moodle, a new system, was introduced to replace the old system because the department's information needs were not being satisfied [2].
Apart from size, there is a big difference in the roles and participation levels of stakeholders in the project process. In traditional top-down system development projects, it is common for the central IT department to manage projects. Users present requirements for the system, participate in the project, and play an auxiliary role [14]. This is true both in the case of introducing a system through insourcing or outsourcing. By contrast, in BUIS projects, user departments are responsiblefor planning the system to be developed, selecting development vendors, and managing projects [2], [13]. Central IT departments have no active role during the project and the level of participation is also very low.
Even after the end of the project, the role of stakeholders differs greatly from that in existing system development projects. Once BUIS systems are complete, system administration responsibilities are effectively transferred to IT departments, not the user departments. Completed BUIS systems require harmonization and integration at the organization level due to administrative issues such as legal compliance and organizational strategy considerations, as well as due to technical requirements such as infrastructure, network, compatibility, and security [15]. Even if the technical issues are resolved and the system is used, the BUIS system can present several challenges throughout the organization owing to its management, and the management issues of the organization [16]. This is the case in the banking example mentioned earlier. Owing to the numerous apps, the domestic financial industry eventually had to go on an “app diet,” to try to shrink and integrate the apps, paying the price in terms of wasted costs and customer confusion [3], [4].
Fig. 1. Representative distinctive properties of BUIS projects
2.2 IS Development Control and Project Performance
Control refers to mechanisms used to "perform calculations in accordance with established plans and standards, quality standards, and organizational goals and values [17]." Control mechanisms used as part of a control activity are specific activities of an information system process that support management in achieving organizational goals. They are specific actions (e.g., who will do what, when, etc.). Developers can verify the requirements of new information systems using control mechanisms such as user storytelling. Control mechanisms include those that control who is involved in the control (for example, users and developers), when controls should be used (for example, when requirements for new systems are collected and identified), and those that involve control documentation system requirements and user story comparisons [6].
Studies on control in information system development projects have focused on top-down information systems, which are large in size and complex in nature. The methods used in the research are mainly case studies and surveys, and most of them, except for some recent studies, are directed toward top-down information systems. Table 1 presents details of previous studies on the control of information system development projects. Cram et al. (2016) [19] identified a control portfolio at the time of system development through outsourcing. Moody et al. (2016) [11] identified the role of field control, which has not been revealed in large-scale cyber infrastructure projects to date.
Table 1. Prior studies on controls in information system development projects
Control modes are a framework for classifying control mechanisms, largely divided into formal and informal controls [5], [18]. Formal control refers to an objective mechanism that is used to assess and compensate for performance to achieve a specific goal [17], [18]. Like formal controls, informal controls also assess performance and provide compensation for achieving goals. However, informal controls are less objective, generally implicit, and not management-centric.
These types of control or their combined control mechanisms are known to influence the performance of information system development projects [5], [8]. System development performance, considered a result of control, has been discussed in terms of various aspects such as project schedule, budget, and system quality. Table 2 presents the aspects of system development outcomes discussed in the control outcome and examples of each.
Table 2. Relationships between control and sub-dimensions of systems development performance
3. RESEARCH AGENDAS REGARDING BUIS PROJECTS AND CONTROL
According to previous studies, large and complex IS projects are governed by a variety of formal and informal mechanisms including project plans, peer pressure, and target budgets and schedules [6], [17]. These projects are usually top-down, under the control of an enterprise-wide plan and budget, controlled by the central IT department, and supervised by top management. Actual controls are established using a portfolio of formal and informal mechanisms rather than a single mode of control [12]. However, it is difficult to apply the results of previous studies to bottom-up type projects, which are initiated on a small scale in user departments—such as BUIS projects—and spread throughout the company. This is because BUIS projects are very different from existing top-down information system development [2], [13].
BUIS projects are designed to meet many goals. Such goals include not only those of the user departments responsible for system development, but also those of IT departments to integrate and harmonize the developed systems and top managements’ interests. In addition, when system development is initiated, the goals of the user department clash with organizational goals when the development is adopted by the entire organization after completion, or the goals are changed [13]. Coordination of various stakeholders and cooperation in this situation is a significant challenge [11]. Without effective control, it will be almost impossible to assure successful project results [6]. Like other IS projects, BUIS projects will use control portfolios and are expected to change the combination of controls as the project progresses. Existing control modes can also be used in unexpected ways, reflecting the new context of the BUIS project. Many studies to date have not provided sufficient insight to understand the control portfolio used in BUIS projects. Thus, this leads to the following research agenda: BUIS project control in terms of developmental stages (agenda 1).
BUIS projects are only undertaken when a need is expressed by end-user departments. These needs arise when the current system of the organization does not meet their requirement, or there are problems with the current process [2]. These internal demands are driven by the development of IT technology (e.g., software as a service or cloud computing) and new payment methods (e.g., subscription payment). Therefore, during BUIS projects, the control of user departments is dominant, rather than participation and control by IT departments.
User departments exercise a variety of formal and informal controls on system development vendors to ensure project success. By contrast, once a project is completed, the BUIS system undergoes many changes due to its integration and harmonization with the whole system of the BUIS system, management requirements, and the consideration of customers and business strategies [15], [16]. IT departments that have had little control over the progress of the project during this period will have more diverse and stronger formal controls, in addition to informal controls. As we can see from the app development example in the domestic financial sector, the apps developed and launched by the various departments of the bank were deleted, reduced, and integrated at the bank level, not at the department level [3], [4]. This coordination process is driven primarily by the formal control of IT departments, rather than that of user departments. This aspect of control is very different from control in the development of top-down information systems for existing large and complex systems. This discussion leads to the following research agenda: BUIS project control characteristics compared with top-down project control (agenda 2).
Fig. 2. Examples of research agendas regarding BUIS projects and control
Informal controls are a type of control that IT departments typically exercise in the course of BUIS projects. Most of the controls in this process are wielded by user departments toward system development vendors. Because BUIS projects are driven by users’ own plans and budgets, and there is often no direct reporting relationship between user and IT departments, IT departments are encouraged to make informed decisions about system developments initiated by user departments. This includes input controls and outcome controls although it is often difficult to exercise control measures [2], [29]. Instead, it is possible to control projects through informal control mechanisms such as socialization and peer pressure [2]. In addition, there is a high degree of uncertainty as to how projects will be completed when a BUIS project is launched, its final deployment in the organization, and ways to achieve the desired results [13]. As a result, IT departments often use informal controls to promote relationships and collaborations with user departments. However, given that IT departments are not in direct charge of these projects and only support user departments, it is not clear how they will exercise informal control over user departments. This discussion leads to the following research agenda: BUIS project control portfolios and mechanisms before system deployment (agenda 3).
If informal controls are dominant during a project, formal controls will appear as new forms of control by IT after project completion. BUIS systems developed by user departments are used by IT departments to meet the technical requirements or capabilities of the organization as a whole (e.g., use of infrastructure such as network servers, security, network efficiency, and compliance with technical standards). This is a necessary control [2]. In addition the comparison of the features of the new system with those of other systems, their integration, and the expansion to the organization as a whole can be extended beyond simple informal control to formal control. At this stage, IT departments can review the work that has been done in the meantime (output control) and control it through regular meetings with user departments (behavior control) [29]. However, given the fact that the project is virtually closed and the developed system should be integrated and coordinated across the organization, it is not clear how an IT department will exercise formal control over a user department. This discussion leads to the following research agenda BUIS project control portfolios and mechanisms after system deployment (agenda 4).
4. CONCLUSIONS AND IMPLICATIONS
In this study, we tried to present a new research direction on the relationship between BUIS project control and performance. This study explored control in BUIS projects, a topic not covered in existing studies regarding control, and thus enables the application and use of control in a new context. First, from the academic point of view, this study suggests that research on information system control is not limited to traditional top-down system development projects, but also to bottom-up project development. Previous studies on control in the existing information system sector have focused on system development projects that are large and complicated and follow a top-down development method. However, with the proliferation of IT, there has been a clear limit to the application of previous research results on bottom-up information system development projects to BUIS projects, which have been growing in number in recent years [2]. This study suggests a new research direction of effective control for BUIS projects.
Second, this study suggests a new role for the IT department to keep pace with the proliferation of BUIS projects. Traditional IT departments have been responsible for the development and management of systems in a centralized manner with enterprise-wide planning and budget. Therefore, it is true that the role of the IT department has focused on managing and controlling major IT issues or projects of the organization [6]. However, the proliferation of BUIS development has resulted in projects that need to be supported by IT departments in a consultative capacity to be successful. This study suggests a new role for IT in BUIS project control.
In this study, the following practical contributions can be found. As in the case of domestic banking [3], [4] as described above, if the BUIS project is not controlled properly during the process, it will impair system performance, result in duplication, incur waste development costs, and high change management costs. This problem is presently bothering many companies, and with the increase of BUIS projects, it is also becoming an increasingly important issue [2]. This study will help to improve corporate performance through effective control and provide research on how to improve actual project performance and improve corporate performance.
ACKNOWLEDGMENT
This work was supported by Gyeongnam National University of Science and Technology Grant in 2018~2019.
References
- H. Liang, N. Saraf, Q. Hu, and Y. Xue, "Assimilation of enterprise systems: The effect of institutional pressures and the mediating role of top management," MIS Quarterly, vol. 31, no. 1, 2007, pp. 1-29. https://doi.org/10.2307/25148778
- C. Chua and V. C. Story, "Bottom-Up Enterprise Information Systems: Rethinking the Roles of Central IT Departments," Communications of the ACM, vol. 60, no. 1, 2017, pp. 66-72. https://doi.org/10.1145/2950044
- Chosun Ilbo, "29 Banks in one bank, what to write," Jan. 25, 2017.
- Hankook Ilbo, "Bank favored the exchange rate of the apps and laid back: Banking app dilemma," Feb. 8, 2017.
- L. J. Kirsch, "The management of complex tasks in organizations: Controlling the systems development process," Organization Science, vol. 7, no. 1, 1996, pp. 1-21. https://doi.org/10.1287/orsc.7.1.1
- L. J. Kirsch, "Portfolios of control modes and IS project management," Inform. Systems Research, vol. 8, no. 3, 1997, pp.215-239. https://doi.org/10.1287/isre.8.3.215
- W. G. Ouchi, "A conceptual framework for the design of organizational control mechanisms," Management Science, vol. 25, no. 9, 1979, pp. 833-848. https://doi.org/10.1287/mnsc.25.9.833
- V. Choudhury and R. Sabherwal, "Portfolios of control in outsourced software development projects," Information Systems Research, vol. 14, no. 3, 2003, pp. 291-314. https://doi.org/10.1287/isre.14.3.291.16563
- S. Rustagi, W. R. King, and L. J. Kirsch, "Predictors of formal control usage in IT outsourcing partnerships," Inform. Systems Research, vol. 19, no. 2, 2008, pp. 126-143. https://doi.org/10.1287/isre.1080.0169
- L. M. Maruping, V. Venkatesh, and R. Agarwal, "A control theory perspective on agile methodology use and changing user requirements," Inform. Systems Research, vol. 20, no. 3, 2009, pp. 377-399. https://doi.org/10.1287/isre.1090.0238
- G. D. Moody, L. J. Kirsch, S. A. Slaughter, B. K. Dunn, and Q. Weng, "Facilitating the Transformational: An Exploration of Control in Cyberinfrastructure Projects and the Discovery of Field Control," Inform. Systems Research, vol. 27, no. 2, 2016, pp. 324-346. https://doi.org/10.1287/isre.2016.0619
- R. W. Gregory, R. Beck, and M. Keil, "Control balancing in information systems development offshoring projects," MIS Quarterly, vol. 37, no. 4, 2013, pp. 1211-1232. https://doi.org/10.25300/MISQ/2013/37.4.10
- C. Lacey, "Shadow IT Goes Mainstream," Unisys blog, May. 6, 2015. http://blogs.unisys.com/financialindustryinsights/shadow-it-goes-mainstream/
- H. Barki and J. Hartwick, "User participation, conflict, and conflict resolution: The mediating roles of influence," Information Systems Research, vol. 5, no. 4, 1994, pp. 422-438. https://doi.org/10.1287/isre.5.4.422
- D. Greefhorst and E. Proper, Architecture Principles: The Cornerstones of Enterprise Architecture, Springer- Verlag, Berlin, Germany, 2011.
- M. M. Zoet, A. W. Heerink, M. M. Lankhorst, S. J. B. A. Hoppenbrouwers, and W. V. Stokkum, "An agile way of working," In Agile Service Development: Combining Adaptive Methods and Flexible Solutions, Springer-Verlag, Berlin, Germany, 2012, pp. 111-140.
- W. J. Orlikowski, "Integrated information environment or matrix of control? The contradictory implications of information technology," Accounting, Management Information Technology, vol. 1, no. 1, 1991, pp. 9-42. https://doi.org/10.1016/0959-8022(91)90011-3
- B. J. Jaworski, "Toward a theory of marketing control: Environmental context, control types, and consequences," Journal of Marketing, vol. 52, no. 3, 1988, pp. 23-39. https://doi.org/10.2307/1251447
- W. Cram, K. Brohman, and B. Gallupe, "Information Systems Control: A Review and Framework for Emerging Information Systems Processes," Journal of the Association for Information Systems, vol. 17, no. 4, 2016.
- A. Dennis, L. Robert, A. Curtis, S. Kowalczyk, and K. H. Bryan, "Research Note---Trust Is in the Eye of the Beholder: A Vignette Study of Postevent Behavioral Controls' Effects on Individual Trust in Virtual Teams," Information Systems Research, vol. 23, no. 2, 2012, pp. 546-558. 10.1287/isre.1110.0364.
- M. L. Harris, A. R. Hevner, and R. W. Collins, "Controls in Flexible Software Development," Communications of the Association for Information Systems, vol. 24, no. 3. 2009. http://aisel.aisnet.org/cais/vol24/iss1/43
- L. J. Kirsch, "Deploying Common Systems Globally: The Dynamics of Control," Information Systems Research, vol. 15, no. 4, 2004, pp. 374-395. 10.1287/isre.1040.0036
- L. J. Kirsch, D. G. Ko, and M. H. Haney, "Investigating the antecedents of team-based clan control: Adding social capital as a predictor," Organization Science, vol. 21, no. 2, 2010, pp. 469-489. https://doi.org/10.1287/orsc.1090.0458
- A. Gopal and S. Gosain, "The Role of Organizational Controls and Boundary Spanning in Software Development Outsourcing: Implications for Project Performance," Information Systems Research, vol. 21, no. 3, 2010, pp. 960-982. https://doi.org/10.1287/isre.1080.0205
- J. Jiang, G. Klein, H. Hwang, J. Huang, and S. Hung, "An exploration of the relationship between software development process maturity and project performance," Information & Management, vol. 41, no. 3, Jan. 2004, pp. 279-288. http://dx.doi.org/10.1016/S0378-7206(03)00052-1
- S. R. Nidumolu and M. R. Subramani, "The Matrix of Control: Combining Process and Structure Approaches to Managing Software Development," Journal of Management Information Systems, vol. 20, no. 3, 2003, pp. 159-196. https://doi.org/10.1080/07421222.2003.11045774
- A. Tiwana and M. Keil, "Control in Internal and Outsourced Software Projects," Journal of Management Information Systems, vol. 26, no. 3, 2009, pp. 9-44. DOI:10.2753/MIS0742-1222260301
- A. Tiwana, "Systems Development Ambidexterity: Explaining the Complementary and Substitutive Roles of Formal and Informal Controls," Journal of Management Information Systems, vol. 27, no. 2, Fall 2010, pp. 87-126. https://doi.org/10.2753/MIS0742-1222270203
- M. Wiener, M. Mahring, U. Remus, and C. Saunders, "Control configuration and control enactment in information systems projects: Review and expanded theoretical framework," MIS Quarterly, vol. 40, no. 3, 2016, pp. 741-774. https://doi.org/10.25300/MISQ/2016/40.3.11