Group 5 Analysis Group 5 INSS 605.WB2 1. How well did each project elicit user information requirements, and how well did it incorporate end-user involvement? Should anything in this regard have been done differently? The case study titled “The public procurement of information systems: dialectics in requirements specification” by Carl Eric Moe and Mike Newman analyzes the process “of three different public procurement projects in municipalities in Norway.” [Moe, 2016] The researchers show that often public entities face numerous hardships in order to acquire IS (Information systems) that comply with their own requirements due to government regulations. All three cases used different procurement procedures which naturally led to different results. In the first case, one of the municipalities initiated a project for the procurement of a claim system and implemented an open tendering system. The requirements specifications for this project were borrowed from another two municipalities and later, they were tailored to their specific needs. The end-user involvement in this project was poorly managed as the project group consisted of only one person from the claims department who was also responsible for training and assisting other employees who would use the new software. The disadvantage of building a strong project team with more members representing the claims department also led to poor implementation of end-user requirements. In addition to limiting the project group, the procurement procedure also prevented the municipality from successfully acquiring the new claim system. The procedure that was selected for this procedure constrained the project members from regular communication with the vendors which could have presented them with valuable industry information. Furthermore, a year after the implementation of the new system, the employees were still experiencing problems with it which further shows the lack of communication not only between the vendor and the municipality, but also between the municipality and its employees 1 Group 5 INSS 605.WB2 during and after the project. Similarly, to the first case, the second case also had a limited number of group members who were part of managing the procurement project. Unlike the first case, the procurement procedure that was selected for this case greatly aided the process in terms of communication and implementing information requirements. The major issue for these two cases and the implementation of the new systems is the size and complexity of the proposed system. Both cases required the new system to be able to integrate with an already existing system and served many groups within the municipality. The inability to involve all stakeholders early in the process led to multiple issues later in the process and in some cases after the project close-out. Lastly, the third case that the authors presented shows a project group that entirely consisted of IT staff which was the procurement entity and a procurement procedure that allowed them to form and finalize their information requirements throughout the project. The competitive dialogue procurement procedure that was selected for this case allowed the project group to fully communicate with the vendors who qualified to bid on the project and have meetings which led to collaboration on both sides. In conclusion, the “The public procurement of information systems: dialectics in requirements specification” by Carl Eric Moe and Mike Newman shows how the lack of end-user involvement can lead to poor system implementation. The case study “How do requirements evolve over time? A case study investigating the role of context and experiences in the evolution of enterprise software requirements? by Stephen Schneider and Jan Wollersheim follows the implementation of a new CRM (Customer relationship management) service, called RightNow, in the two subsidiaries, Online Marketplace (OM) and Internet Marketing (IM), of the German company, Alpha. The process that took place in the OM subsidiary and its CS (Customer Service) division was entirely managed by its 2 Group 5 INSS 605.WB2 employees who “evaluated and tested three preselected ticketing systems in detail” (Schneider, 2018) but due to the constant evolvement of the user requirements, “OM refocused its efforts on finding a CRM service.” (Schneider, 2018) Furthermore, due to lack of resources in their IT department, this division was excluded from the software purchase and its implementation which led to “hiring a consultancy for the initial setup in 2008 and to provide training.” (Schneider, 2018) As the researchers point out in the case study, there are multiple factors that can be attributed to the problems that OM experienced during the RightNow rollouts, including the lack of end-user involvement during the sales rollout, the over-configuration and over-customization” (Schneider, 2018) To conclude, it can be said that “the continuous evolution of the service” that OM has adopted, the lack of a clear implementation plan, and input from all stakeholders led to the multiple issues that the subsidiary experienced during rollouts including an increased financial burden. The third case study by Sukeshini A. Grandhi and Babajide Osatuyi titled “If you build it, will they use it? Challenges in adoption and use of patient-centered e-health”, provides the analysis of the implementation of a system that entirely depends on end-user feedback. In this study, the researchers had interviewed 15 Connecticut state employees with the main goal to see why or why not employees use the freely available website called HEP provided by their employer. Unlike the other case studies presented earlier in the analysis, this one depicts the direct relationship between a web-based product and its users. By obtaining feedback about usability, scheduling and coordinating preventive care, and managing and tracking preventive care, the researchers were able to conclude the many reasons why users were not adopting the program. In order to achieve greater usability amongst state employees, the employer could roll out an advertisement campaign that provides more information on the advantages of this service. 3 Group 5 INSS 605.WB2 Moreover, instead of conducting interviews after the implementation of the service, the state could have held multiple focus groups throughout the process, so the employees' feedback could have been implemented immediately. 2. How well did each project consider various managerial, organizational, and technological aspects? The first case study titled “The public procurement of information systems: dialectics in requirements specification” by Carl Eric Moe and Mike Newman illustrates how the public procurement of Information Systems (IS) can be a highly complex process. As it is stated in the case study, there were various challenges that were faced by the procurement entities to implement these projects, and one of the biggest challenges relates to the requirements specification. There are three different cases that were researched and the first one is about a claims system in which an open tendering procedure was used. In the second case, the system that one of the municipalities was implementing was the electronic health record system and tendering with negotiations procedure was used. Lastly, in the third case, a system for archive and backup was adopted by the IT department and a competitive dialogue procedure was used. The managerial aspects are blatant in case one; the claims manager initiated the procurement project in February 2012. “She led the project group, which consisted of a super user from the claims department, a super user for the ERP system and the IT technician who was responsible for ERP system operations. A super user is a user assigned the role of expert in his/her functional area, and who trains and assists other users” (Karuppan & Karuppan, 2008). The first case manager excluded vendors who were vulnerable, and this was an important step that she learned in a training course. This shows how vital it is for the manager to take the training course to understand what is necessary and what is not as we learned in chapter one that management 4 Group 5 INSS 605.WB2 should monitor the project and select the system solution. The organization aspect of the project in the second case is that the municipality established a subproject to procure a new EHR system. The project group consisted of four internal staff members: the leader of the message exchange project, the leader of the procurement project, a super user of the old EHR system and the designated. In this project, the final vendor was selected after having multiple meetings with all of the vendors who initially bid on the project. This, on the other hand, allowed the procurement entity to have greater control over the final product that was developed by the vendors throughout the initial project stages. As stated in the case study, the group experienced internal conflicts which shows how organizational culture and open communication within the organization can make a project successful. In the last case, the procuring entity was the IT department in the same municipality as referred to in the first case. The procurement concerned a backend system for backup and archiving, as the old backend system was not expected to be able to cope with the growing amount of data. In case 2, the negotiations identified which requirements were met, and the ranking and selection were quite straightforward. “The procuring entity was very certain of the decision made, and there were no big surprises after implementation.” (Moe) However, it took a long time to develop detailed requirements specifications. In case 3, the dialogue helped the procuring entity to decide on their needs. “The tendering process gave them enough information to decide” (Moe). In case 1, with hindsight, the selected procedure was not right. The entity struggled to implement the new system. If the manager provided constant dialogue to the vendor, possibly through demonstrations with real data, this may have revealed the issue earlier. The most appropriate procedure for case 1 would have been tendering with negotiations but instead, restricted tendering was applied. The procurement manager, though experienced in the workings of the municipality, was new to 5 Group 5 INSS 605.WB2 procurement as stated by the authors. It could be concluded that experience and competence within the project and entity is a critical factor in any successful project. The second case study titled “How do requirements evolve over time? A case study investigating the role of context and experiences in the evolution of enterprise software requirements? by Stephen Schneider and Jan Wollersheim explores how the life cycle of cloudbased ES (enterprise software) in one medium-sized organization evolves throughout the ES life cycle. This five-year lifespan covers from the initial adoption to the retirement of the enterprise system and what aspects lead to these decisions. Additionally, the researchers identified various requirements for the enterprise system that went through an evolution over the five years such as covering decisions, technology, the environment, individual, group, and organization. These requirements shaped the ideas and support of the enduring ES. The managerial aspect of the enterprise system was mentioned in a few key statements. With the usage of RightNow increasing continually, the company, “Alpha had to establish a dedicated CRM manager, who administered the service for both subsidiaries and was accountable for new feature rollouts, configuration, upgrade planning, and training key users.” (Schneider) Since the project was becoming more difficult to handle, they required more assistance than was originally needed. As the project continued to be troublesome for most users, the aforementioned “CRM manager [CM] crafted an initial draft of 15 requirements and evaluated both services on each requirement. Next, [CM] presented his evaluation to the Chief Operations Officer [COO], and they discussed each requirement and the according evaluations of both services in fulfilling the requirements. The COO added his input from a management perspective, which resulted in adjusting the requirements and the evaluation scores of each system on particular requirements.” (Schneider) This all began the initial stages of retiring the enterprise system. 6 Group 5 INSS 605.WB2 Within the technology itself, the company, Alpha, struggled to fully implement the ES over the course of the five years. “Due to a lack of IT expertise in the sourcing team, tremendous effort was made to configure the service, which strained RightNow to the limits of its configurability. The modifications of RightNow became very complex and over specific, resulting in a slow service, complex workflows, and poor usability.” (Schneider) As the technology advanced in age, the problems grew exponentially. “RightNow was never fully accepted by OM’s sales division, where resistance increased over time. An upgrade in 2012 led both divisions of OM to suffer significant downtime, incompatible configurations, changed interfaces, and broken plugins, which ultimately resulted in OM initiating a re-evaluation process.” (Schneider) Instability of the program led to irritability and dissatisfaction of the users based on the outdated information system. In this case, there were several organizational aspects identified by researchers that contributed to the lifecycle of the enterprise system such established relationships, IT division capacities, IT procurement policies made by organization, levels of integration within the organization and an unstructured business process. With these boundaries, the process evidently shows the gradual process from the initial integration to the eventual retirement of the ES within Alpha. The article by Sukeshini A. Grandhi and Babajide Osatuyi titled “If you build it, will they use it? Challenges in adoption and use of patient-centered e-health” centered its managerial, organizational, and technological aspects around the Patient-centered e-Health framework. This framework is focused on the “three aspects of e-health: Patient-focus, Patient-activity, and Patient-empowerment” (Kamis) These three focus groups overlap in conveying the various aspects that are necessary for PCEH to lead to patient centeredness in e-health. “The PCEH framework proposes that the extent to which a PCEH service exhibits patient centeredness 7 Group 5 INSS 605.WB2 influences whether patients adopt and use it.” (Grandhi) This article is focalized on identifying through semi-structured interviews with those that have interacted with the website whether the Health Enhancement Program (HEP) in Connecticut created a patient-friendly website that was easy to use and comprehensible for all those that needed to enter it. In the case of the managerial aspects to the article, an app or website is created to ease the burden of the manager’s duties instead of completely replacing him. “In other words, people in a growing number of organizations are using what are often called decision support systems to improve their managerial effectiveness.” (Alter) These systems are used in a variety of ways depending on its original structure and layout but are created to improve “interpersonal communication, facilitating problem solving, fostering individual learning, and increasing organizational control.” (Alter) In the article, they generally do not specifically highlight the managerial aspect of the case study, but it is often included in between the pieces of the PCEH framework. From the homepage of the website, patients were able to log in or create a new account, access the HEP requirements, chronic conditions, help and forms, contact, schedule a physical, enrollment information, home, forms, health resources, and messages. All of these capabilities would make it easier for patients to access information on their own without assistance, giving the healthcare system more time to focus on the patients while in appointments. While at first glance, the website is created with patients in mind, the assessments that the researchers compiled were not as positive overall. From the design assessment, all three assessments were medium-high to high while from the user perspective each section was rated low. The initial managerial ideas were in place, but the real-world usage was not. This leads to the organizational aspect of the website. The planner that was given to users to inform them of the website detailed what could be completed there: “1) view HEP preventive 8 Group 5 INSS 605.WB2 and chronic requirements, 2) download HEP forms, 3) check their HEP preventive and chronic compliance status, 4) complete their chronic condition education and counseling compliance requirements, 5) access a library of information and articles, 6) set and track their personal health goals, and 7) exchange messages with HEP nurse case managers and professionals” (Grandhi) which mostly follows along with what could be seen from the homepage of the portal. However, when interviewed, users found most pieces to be challenging, from logging in to adding the website into their health routine. The three most common themes that the researchers found from the interviews were challenges with usability, scheduling and coordinating preventive care, and managing and tracking preventive care. “Respondents also expressed difficulty in finding and updating information on the portal. Jason, an academic associate in his 50s, talked about how he had difficulty in finding an online survey as one of the HEP requirements for a chronic condition he had.” (Grandhi) If patients cannot easily find the information that they need on a website, then it is not properly organized to be fully patient-centered. Furthermore, the organizational aspect clearly leads into the technological aspect of the portal. While the Connecticut State Government constructed the website with patients in mind, it clearly had patients confused as to how to utilize the portal to the best of its capabilities. “On the visiting portal, respondents mentioned several usability issues about signing in and accessing it. They expressed frustration about not knowing how to even access the website even if they knew about availability. For example, Charles, an assistant to the housing director and in his 20s, said: ‘―I don’t even know how to access the website honestly. I wouldn't even know what to be looking for at this point.’” (Grandhi) If one patient has such difficulties trying to use the website on their own, there are many others that are struggling to understand how to use it. Another interviewee stated how she was unable to use the system to update her eye appointment online. 9 Group 5 INSS 605.WB2 While the article covered the managerial, organizational, and technological aspects of the HEP Web portal, the Connecticut State Government did not fully create a page that eased patients’ lives with the website. 3. What lessons were learned regarding organizational change in systems development? There are many lessons learned regarding organizational change in the three cases presented in this analysis. One in particular is the role of the end user. “System implementation generally benefits from high levels of user involvement and management support” (Laudon & Laudon). Information systems specialists have a more technical problem-solving approach. “They look for elegant and sophisticated technical solutions in which hardware and software efficiency is optimized at the expense of ease of use or organizational effectiveness.” (Laudon & Laudon 2020). This leads to user requirements not being properly incorporated into information systems. This is evident in the Patient-centered E-health case. In the study “participants communicated their perspectives about and challenges in using the HEP Web portal.” (Grandhi & Osatuyi 2018). Users reported difficulty in usability of the site, scheduling appointments and managing their preventative care. “Data showed that respondents found both accessing and using the portal challenging” (Grandhi & Osatuyi). “The assessment of patient centeredness of the HEP web portal showed that the site had low patient focus, patient activity, and patient empowerment.” Grandhi & Osatuyi). Users struggled to use the site. They had to rely on other ways of tracking their appointment and rely on other methods for managing their preventative care. If the designers of the site had users test the site beforehand, they would have been able to correct some of the issues of the site. They would have been able to tailor it to better fit the user’s needs, which in turn would have made it more accessible and more users would have adopted it. 10 Group 5 INSS 605.WB2 The role of the end users is also prevalent in the enterprise software requirements case. “Due to a lack of IT expertise in the sourcing team, tremendous effort was made to configure the service, which strained RightNow to the limits of its configurability. The modifications of RightNow became very complex and over- specific, resulting in a slow service, complex workflows, and poor usability” (Schneider et al. 2017). Instead of tailoring the business process to fit with RightNow, they modified the system instead. That along with the lack of support and training for the users proved to be very difficult to manage. The company should have looked at the needs of all those involved and picked the service that suited everything. They should have also opted for the premium support even if it cost more money as they needed that support for the users that were having difficulties. Another lesson that was learned is change management and implementation. “A very large percentage of information systems projects stumble because the process of organizational change surrounding system building was not properly addressed. Successful system building requires careful change management” (Laudon & Laudon 2020). Companies have to look at the new system that they are going after and make sure that it fits all of their needs and the needs of everyone involved. In the requirements specification case, it followed three procurement projects and the requirements needs. For the first case they chose a vendor based on reviews for others that were using it. They figured if it worked for them it would work for us. However, “in the implementation phase, it was emphasized that an important feature of the claims system was its integration with the ERP system already in use. A few days prior to the installation, the project group discovered that the claims system was incompatible with their existing version of the ERP system; and a new version of the ERP system was needed” (Moe, Newman, & Sein 2017). Had 11 Group 5 INSS 605.WB2 they asked questions about the system and the capabilities they would have realized that the system they were procuring was not compatible with their current ERP system. In the second case they spent a lengthy amount of time coming up with the system requirements. They took information for others that had been using different vendors and seeing how they were doing things. They then had interviews with the vendors they were interested in. The vendors went through requirements, addressed how they would handle issues and demonstrated their system to most of the project group and the whole reference group. The new system faced some changes with the old system but was able to go live as planned and on time. The company in the second case did the research first, they gathered information based on requirements they needed as well as looking at other companies of similar size. Then when the vendors were there they were able to address all of the concerns and see how the vendors would deal with any issues that arose. The fact that they included a person from each group that would be using the system to join in assessing the vendors and the systems made the implementation portion smoother. In the third case they actually sat down with the vendors and came up with a list of requirements together. They had another meeting for the vendors to present their ideas of what was needed and their solutions. After the final vendor was selected the implementation process followed it included training for some users. This process offered the most benefit as it allowed the company to assess the vendors before they made their decision. They worked hand in hand with the vendors to come up with the requirements to make sure everything would work with what was needed. The lesson of change management and implementation was also learned in the enterprise software requirements case. When Alpha decided to go with RightNow they didn’t include their 12 Group 5 INSS 605.WB2 IT department. “Flexible licensing options paired with UI-based configurability and self-service acquisition possibilities enable business divisions to acquire ES without involving IT expertise. OM’s requirements in 2007 were predominantly business-driven, targeting the distinct business goals of the CS division. However, OM’s requirements in 2012 were far more concerned with IT-specific requirements, as OM recognized the importance of IT-specific requirements over time.” (Schneider et al. 2017). This shows that Alpha learned from their mistake of not including all departments and stakeholders in the decision to roll out RightNow. They took everyone to account when they reevaluated their requirements and what they needed out to the system. Even though they continued to use RightNow they changed some of the ways they did things to benefit the whole company. 13 Group 5 INSS 605.WB2 References: Alter, S. L. (2014, August 1). How Effective Managers Use Information Systems. Retrieved April 24, 2020, from https://hbr.org/1976/11/how-effective-managers-use-informationsystems Grandhi, S. A. & Osatuyi, B. (2018). If You Build It, Will They Use It? Challenges in Adoption and Use of Patient-centered E-health. Journal of Information Technology Theory and Application Vol. 19. Kamis, Arnold & Yao, Chrisy & Kim, Seokjin. (2014). An Empirical Validation of the Patientcentered e-Health Framework in Patient-focused Websites. Communications of the Association for Information Systems. 34. 477-492. 10.17705/1CAIS.03425. KARUPPAN CM and KARUPPAN M (2008) Resilience of super users’ mental models of enterprise- wide systems. European Journal of Information Systems 17(1), 29–46. Laudon, K. C., & Laudon, J. P. (2020). Management information systems: managing the digital firm (16th ed.). Schneider, S., Wollercheim, J., Krcmar, H., & Sunyaev, A. (2018). How do requirements evolve over time? A case study investigating the role of context and experiences in the evolution of enterprise software requirements. Journal of Information Technology (2018) 33, 151– 170 Moe, C. E, Newman, M. & Sein, M. K. (2017). The public procurement of information systems: dialectics in requirements specification. European Journal of Information Systems (2017) 26, 143–163 14 New! Re: Group 5 Analysis P 21, 2020 3:48 PMV) - Reau vy.3 Mark as Read Reply Thank you for this in depth analysis guys! One of the most interesting aspects of your analysis was the lesson learned regarding the importance of a user role system development. I definitely agree that system development can sometimes focus very heavily on the improvement and sophistication of the system itself, while user experience is an afterthought. For a company to improve their processes, they must not only look at the efficiency and efficacy of the system, but also how user will react and utilize these new changes. If users find the new system difficult to manage and navigate around, they will find such a system invaluable. New! Re: Group 5 Analysis (Apr 28, 2020 4:43 PM) - Read by: 1 M Mark as Read Reply Great Analysis Group 5! I also found the proposed question around end user involvement and how this plays a role in adoption most interesting, as this is something that is often discussed in my role at work. End user involvement is almost always critical to the success of a project and can often help to alleviate training required post implementation. All three of these case studies could have improved upon how they worked with end users throughout the various projects. The three procurement cases should have done a more in depth analysis of the end users requirements beyond just one or two people. While the IT team probably knows the system like the back of their hand, they do not know what processes are or are not work for the end users. Having this in depth analysis of requirements would have helped to score potential solutions more accurately. The second case study about "how requirements evolve over time", demonstrates how it is important to have the appropriate balance of end users as well as members of the IT organization. Like I mentioned previously, the end users know the processes, but the IT team knows the architecture and speak to the reality of how feasible a requirement is and how a new system will fit into the company's current landscape. This case was lacking IT resources which ultimate led to the requirement scope to continue to increase and evolve. The last case study "If they build it will they use it?" shows a good example of conducting retros post implementation. However, this is something that would be most beneficial to do throughout the implementation process, this way you can make adjustments to your progress depending on how well you are meeting the end users needs.
Purchase answer to see full attachment