How Stage Gate Process Supports CbC: Case Study

Transcription

1 How Stage Gate Process Supports CbC: Case Study R. Alvarez*, K. Domínguez **, M. Pérez**, L. Mendoza** * Ingeniería de la Computación, Universidad Simón Bolívar, Baruta, Venezuela. ** Laboratorio de Investigación en Sistemas de Información, Universidad Simón Bolívar, Baruta, Venezuela. s: @usb.ve, [email protected], [email protected], [email protected] ABSTRACT In this article it is presented how a Stage-Gate process was adapted to support CbC: An additional activity was added at the beginning. Corporate templates as well as interviews were used for the analysis. Developers received training in the configuration activity. Validation and technical tests were conducted for the System Testing and finally attendance and distance trainings were made in the final stage. This is how besides refining a Stage- Gate process CbC is reaffirmed as a valid proposed methodology for configurable systems. KEY WORDS Stage-Gate process, Construction by Configuration, Software Engineering. 1. Introduction Advances on Information Technology motivate organizations to be constantly updated to maintain a competitive advantage over its competitors. This implies, in Software Engineering, constant changes in the way the applications are developed. That is why the software adaptation becomes increasingly frequent. Thus, it becomes increasingly necessary to have a methodology that formalizes the activities that are already being done. This article approaches how Sommerville s proposed methodology Construction by Configuration (CbC) [1] was instanced in a Stage- Gate process used in a large mass consumption company. According to Sommerville two of the main issues that led to problems in the deployed configured systems are the co-design of process and software and the adhoc testing [1]. These risks were approached with corporate formats for user involvement as well as workshops with groups of users that should represent the types of users. The second by taking advantage of the fact that preexisting processes and systems were in place for the time of the testing, so that the results and outcomes of the test could be compared to ensure liability. The main conclusion is that CbC can be successfully instanced by a Stage-Gate process with the addition of a stage and its corresponding gate. This article is presented as follows. First a brief description of the configurable system used in the case study: AquaLogic User Interface (ALUI). Then a description of the Stage-Gate Process used in CbC. The next topic has the description of the phases of CbC and how it complies with the case study. Finally, the conclusions derived from the research. 2. AquaLogic User Interface AquaLogic User Interface (ALUI) is capable of integrating existing systems and information on an organization. It has components that allow the creation of a solution that effectively integrates diverse platforms and systems [2]. It provides high level of personalization and security management for groups and users [2]. More specifically, Portlets are used to embed web applications into the portal page [3]. For this project, the regional division of the IT department of the company was assigned with the responsibility of implementing the AquaLogic User Interface in the Andean Region in the sales organization. The objective is to increase productivity by providing a single place for the information, thus discouraging a large group of s through collaboration and to improve the overall productivity. To the company, the AquaLogic User Interface has the objective of improving fundamental business processes, and as will be explained below, required the redesign of business processes, it is organized in modules for the different tools it is capable of integrating, has a scope of business and employees at all levels, thus it complies with the characteristics of an Enterprise Resource Planning (ERP) [4],[7]. 3. Stage-Gate Process A Stage-Gate process is a map used for moving products from idea to launch and even maintenance, it sets the concepts and the activities that are necessary [5]. Each stage is designed to gather more information on possible risks, issues and how to tackle them, and they cost more than the preceding stage [5]. Right after every stage is a gate, which is basically a Go/Kill decision based on the information gathered during the last stage, and they consist on deliverables (for which the project leader is

2 accountable) and the criteria used to judge the project [5]. With the purpose of keeping the confidentiality of the large mass consumption company, owner of the Stage-Gate process used for the implementation of the system subject of this study, the stages will have the following dummy tags: Idea, Create, Develop, Prepare, Launch. The transition between each stage is achieved by succeeding at the corresponding gate, which will be named with the stage that is being left behind followed by the stage that is beginning, for example the deliverable gate between Create and Develop will be named Create-Develop gate, as depicted in fig. 1. Fig. 1 Stage-Gate process used by the company Idea, the first stage, is as its name reveals the moment when the idea arises, when the project begins to be conceived. The purpose of this stage is to achieve initial compromise and resource allocation for the project, and ends with the corresponding Idea-Create gate. Create stage is mainly dedicated to ensure feasibility, measure possible success for the project, as well as an overall prototype of what the project will be like, and ends with the Create-Develop gate. Once again this gate looks once again for Go/Kill decision from corresponding leadership. The Develop stage is the time for the actual development of the system, technical capabilities are put in place and project leaders make constant revisions of the ongoing events. This activity ends with the deliverable gate Develop-Prepare, which is revised by decision-makers to make final commitment with the product. During the Prepare stage the main idea is to gain sponsorship for the system, to ensure adoption, so that benefits can be perceived. For this reason minor final details of the system are arranged in this stage, to get final commitments on the dates for the official launch and other activities such as user trainings, and ends with this commitment expressed in the Prepare-Launch gate. The final Launch stage is the execution of all the committed plans, as well as other maintenance measures used to keep users up-to-date with the offered tools. Large mass consumption companies need to be constantly innovating in order to maintain their market shares. This case study revises the use of a Stage-Gate Process used by the company, 4. Construction by Configuration (CbC) This work explains how the CbC approach [1] was applied in this case study. It also includes how the Stage-Gate process used by the company to launch their systems, is embedded with CbC in this system configuration. In this project the customer is the sales organization of the mass consumption company in the Andean Region (Latin America). The product offered is a single place where they can find all the information needed to track the business, which brings into place new capabilities and integrates ongoing solutions used by the organization. It will save time as users will not need to search in reports, systems, informal communications and others, it will save space in the servers as information will not be shared this way, and will ensure that the information being viewed is as updated as is available. All this existing overhead generates a gap between the productivity expected and delivered, which motivates the creation of this project. 4.1 System Selection As stated in [1], the system selection is based on high-level business, so constraints such as acquired software, business standards, corporate values and objectives as well as ongoing standardization will set the boundaries for this analysis. The characteristics that make the AquaLogic User Interface superior to the option of Shared Network Disk Drives, Lotus Notes Teamspaces, and Microsoft Sharepoints alone were the following: 1. AquaLogic User Interface is a solution already supported within the company, thus ensuring scalability beyond the current Regional scope, building upon the company s IT department principle of scalability, and handles the risk of future technical support availability. 2. Integration of other previous solutions into one interface to allow a smooth transition from many places to search for information to a single place with all the information the user needs, and thus including all of other solutions capabilities and advantages. 3. High level of configurability that can be made by the developer to minimize user manual configuration, allowing groups of users to have almost personalized tools that adapt to their profiles within the company. The Stage-Gate process used by the organization does not contemplate any stage or gate for system selection, thus the decision making was based in general policies and principles of the company and its IT department. If the organization wishes to instance

3 CbC for its configurable systems, the Stage-Gate process would need an additional stage and gate, or additional activities for the Idea Stage. 4.2 Requirement Analysis The requirements were set up according to the Idea Stage of the Stage-Gate process used by the organization to establish user needs and feedback. Corporate templates used served as a great guideline as they were capable of retaining user aspirations, needs and even proposals without going too deep into technical details, which depend on the ERP. Individual interviews where held in order to attend every particular need that could arise, as well as possible issues and specific details regarding the integration of other systems and solutions into the interface. Some of the requirements where not within the possibilities of the AquaLogic User Interface, and where thus transformed in the next activity so that they would still approach the user requirements and at the same time be adapted to the capabilities of the ERP. Thus, Stage-Gate process can instance this activity of CbC with the stage mentioned above. The corresponding milestone of Idea-Create was the deliverable used at this activity. 4.3 Business Process Redesign Exhaustive research was conducted by revising business documents and reports, interviews with business experts, leaders and stakeholders, and group sessions with representative members of the sales force. Documents and reports were reviewed with the purpose of understanding what is the business interested in tracking and which are the measures that drive decisions. The factors involved where organized in a table (which like other documents can not be shared for confidentiality reasons), and then discussed with the experts and stakeholders to understand the source of the information and its relevance. The sessions with the members of the sales force where focused on the operational aspects of the information, ranging from how and where to obtain it and which processes occurred there, to the processing of the information itself and the methods to communicate the results. The business processes where mapped to local flowcharts, that reflected the reality of every sales unit involved, in order to have a representation of how the process currently works, which are the common features between units, which features are really necessary, how are the function of the member and the activity related, if they are. Fig. 2 is a generic example of how the processes were mapped to reflect current workflow in one of the countries. The analysis was used to create a new process that is feasible, adapts to the way the system works, creates value to the sales organization in terms of time saving and provides clarity and consistency for the business process derived from the use of the system. Fig. 2 Mapped actual processes of country X The documentation and proposed process was shared with the leadership, with extensive explanations and discussions that led to a similar redesign of the business process, reflected in fig. 3, which was accepted by the development team and corresponding leaders. This activity happened within the Create Stage of the Stage-Gate process, resulting in the Create-Develop gate approval. This milestone was capable of effectively formalizing this activity and adapt it to the requirements of approval processes. Once again the process successfully instanced this activity of CbC. Fig. 3 Proposed unified process for the region 4.4 System Configuration There existed an initial limitation for the configuration of the AquaLogic User Interface: the lack of knowledge. The approach was to attend trainings that provided an effective way of

4 understanding the general functioning of the configuration utility of the AquaLogic User Interface. Right after the trainings, access was provided to a dummy system, which was placed in development so that users do not have access to it and it does not affect other ongoing developments or systems that are in place. Due to the lack of previous academic and practical experience and documentation for the CbC approach, at the beginning the learning curve was not very steep, until there was a basic understanding of the configuration options and the scope of such an approach. At that point the learning curve steepened immediately and continued until enough information was available to understand how the capabilities present could be maximized in order to comply with user needs at the best of possibilities. A very useful approach of this technology is the use of Portlets [2] that allows reapplication as they provide the possibility of being saved for a similar future application so that most configuration steps can be saved. However, as suggested in [1], this configurable system doesn t have the capacity of version management, which makes it extremely difficult to revert to previous configurations, especially when the new configuration is undesired [1]. This activity happened within the framework of the Develop stage of the Stage-Gate process, and ended with the milestone of the Develop-Prepare Gate. 4.5 System Testing In recent years, a Model-based Testing approach was proposed, which provided for the automation of the design of black-box tests. [6] defines black-box test where test cases rely solely on the input/output behavior. For the system to be fully qualified and go into production it requires acceptance by a representative group of users. For this purpose, user testing was conducted. The user testing was mainly dedicated to human-computer interface (black-box test), as the main new function is dedicated to the integration of several solutions into one single place, and those mini-systems have already been technically tested and even deployed previously, so except for the new ones, that where thoroughly revised, technical problems are not expected. Users where selected from the different functions, so that every different type of user would be represented in the testing. The sessions were conducted in groups of one (1) to four (4) users at a time, including a local system manager or analyst which is the contact used to get in touch with the user, and adding the interviewer that gave a thorough walkthrough in the functionalities that were used by the interviewee. With the user testing everything was ready for the Gate Prepare-Launch, which was passed successfully with all the needs. The technical testing was dedicated especially to data consistency and was done live taking advantage of the users present in the user testing. This activity of the CbC proposed methodology is successfully covered by the Stage- Gate process. 4.6 Deployment and Evolution Now in the Launch Stage, there was an immediate need to prepare the deployment of the system, to drive the adoption that will be the criteria to define the success of a new system. Final technical performance tests were performed and readiness was confirmed. This activity and stage is currently happening. With the pre-launch marketing in place, the user trainings are being designed in two modalities, attendance sessions, which will be the first to happen as the users currently undergo activities different to the ones proposed by the configured system, and need to be completely changed as was proposed in the Business Process Redesign [1]. The second modality is the digital training, which is aimed at new hires that simply need to have an understanding of how the process works without the need of cultural change. This modality is intended to provide sustainability to the solution, so that the system does not require of ongoing permanent trainings, and thus trainers, allowing it to be self sustaining in this sense. Another special training is currently under development, and it is related to those special users who will be uploading information and providing minor maintenance to some of the sub-systems. The deployment began with pilot users from one of the countries intended to provide learning and measure possibilities of success. These users should also become the first supporters of the transformation as they will be the first to experience the single place with all the information, and the time savings provided by the tool and the culture change. The Stage-Gate process used by the corporation is capable of becoming an instance of this activity of CbC for this activity as well. 5. Conclusions Throughout this text it becomes evident that the process used by the company is perfectly capable of instancing the methodology proposed by Sommerville, previously mentioned as CbC, with the exception of the activity of System Selection. This is probably due to the fact that the Stage-Gate process used by the large mass consumption company

5 applied in this case study is not exclusively dedicated to configurable systems. The main conclusion in this article is that CbC can be successfully instanced by the use of a Stage-Gate process. When configurable systems are being constructed, the addition of a new stage of System Selection and a corresponding gate to pass to the idea stage would result necessary in order to comply with the total proposed methodology, CbC. The CbC approach has its main adversary in configuration changes. This became clear in the case study mainly when the configuration tool was finally understood, due to the fact that all of the knowledge on how configuration changes could affect the final outcome was almost exclusively empirical. Documentation on how a change in one option affects other configuration options is almost missing in the product documentation, and even beyond specific relations among configurations in this particular case study, there is no academic documentation to support the process followed when developing configurable systems. References [1]Sommerville, I. Construction by Configuration: Challenges for Software Engineering Research and Practice, 19th Australian Conference on Software Engineering (pp. 3-11). IEEE, 2008 [2]BEA (2005), BEA AquaLogic User Interaction. Creating Synergy Between People and Your Business, Retrieved October 2008, from: apers/bea_alui_ds.pdf [3]BEA (2008), Introduction to ALI Development. Retrieved September 2008, from: troduction_to_ali_development.pdf, 2008 [4]B. Zhang (2005, March 8), ERP Definition - A Systems Perspective. Retrieved July 2008, from: [5]R. Cooper, Perspective: The Stage-Gate Idea-to- Launch Process Update, What s New and NexGen Systems, Journal of Product Innovation Management, 25(3), (May 2008). [6]SWEBOK Guide to the Software Engineering Body of Knowledge Version. IEEE Computer Society. [7]Sommerville, I. (2006). Software Engineering. 8th Edition. Addison-Wesley