Investigate Further IS Strategy and/or Governance Issues - Management Assignment Help

Assignment Task

Title: Individual Extended and Advanced Case Study Analysis
The aim of the assignment is for you to investigate further IS Strategy and/or Governance Issues through an extended industry case study which has two parts. The case study will be available via Canvas. You are asked to produce a relevant report. In the case study analysis, you will apply advanced principles, techniques and analytical tools of Business IS Strategy and Governance. The report should include a synopsis of the case, a list and analysis of the identified key issues followed by the answers to the questions asked at the end of the case description.
 
The case study part 1 is from: Smith, H. A., and J. D. McKeen (2015). Mini Case “Shared Services at RR Communications.” In McKeen, J. D., & Smith, H. (2015). IT strategy: Issues and Practices (third edition) Boston: Pearson, pp. 178-181, #1-L07-1-002, Queen’s School of Business, reproduced by permission of Queen’s University, School of Business, Kingston, Ontario, Canada

Mini Case: Building Shared Services at RR CommunicationsVince Patton had been waiting years for this day. He pulled the papers together in front of him and scanned the small conference room. “You’re fired,” he said to the four divisional CIOs sitting at the table. They looked nervously at him, grinning weakly. Vince wasn’t known to make practical jokes, but this had been a pretty good meeting, at least relative to some they’d had over the past five years. “You’re kidding,” said Matt Dawes, one of the more outspoken members of the divisional CIO team. “Nope,” said Vince. “I’ve got the boss’s OK on this. We don’t need any of you anymore. I’m creating one enterprise IT organization, and there’s no room for any of you. The HR people are waiting outside.” With that, he picked up his papers and headed to the door, leaving the four of them in shock. “That felt good,” he admitted as he strode back to his office. A big man, not known to tolerate fools gladly (or corporate politics), he was not a cruel one. But those guys had been thorns in his side ever since he had taken the new executive VP of IT job at the faltering RR Communications five years ago. The company’s stock had been in the dumpster, and with the dramatically increased competition in the telecommunications industry as a result of deregulation, his friends and family had all thought he was nuts. But Ross Roman, RR’s eccentric but brilliant founder, had made him an offer he couldn’t refuse. “We need you to transform IT so that we can introduce new products more quickly,” he’d said. “You’ll have my full backing for whatever you want to do.” Typically for an entrepreneur, Roman had sketched the vision swiftly, leaving some-one else to actually implement it. “We’ve got to have a more flexible and responsive IT organization. Every time I want to do something, they tell me ‘the systems won’t allow it.’ I’m tired of having customers complaining about getting multiple bills for each of our products. It’s not acceptable that RR can’t create one simple little bill for each customer.” Roman punctuated his remarks by stabbing with his finger at a file full of letters to the president, which he insisted on reading personally each week. “You’ve got a reputation as a ‘can do’ kind of guy; I checked. Don’t bother me with details; just get the job done.” Vince knew he was a good, proactive IT leader, but he hadn’t been prepared for the mess he inherited—or the politics. There was no central IT, just separate divisional units for the four key lines of business—Internet, mobile, landline, and cable TV service—each doing its own thing. Every business unit had bought its own hardware and software, so introducing the common systems that would be needed to accomplish Roman’s vision would be hugely difficult—that is, assuming they wanted them, which they didn’t. There were multiple sales systems, databases, and customer service centers, all of which led to customer and business frustration. The company was in trouble not only with its customers but also with the telecommunications regulators and with its software vendors, who each wanted information about the company’s activities, which they were legally entitled to have but which the company couldn’t provide. Where should he start to untangle this mess? Clearly, it wasn’t going to be possible to provide bundled billing, responsiveness, unified customer care, and rapid time to market all at once, let alone keep up with the new products and services that were flooding into the telecommunications arena. And he hadn’t exactly been welcomed with open arms by the divisional CIOs (DIOs), who were suspicious of him in the extreme. “Getting IT to operate as a single enterprise unit, regardless of the product involved, is going to be tough,” he admit-ted to himself. “This corporate culture is not going to take easily to centralized direction.” And so it was. The DIOs had fought him tooth and nail, resisting any form of integration of their systems. So had the business unit leaders, themselves presidents, who were rewarded on the basis of the performance of their divisions and, therefore, didn’t give a hoot about “the enterprise” or about anything other than their quarterly results. To them, centralized IT meant increased bureaucracy and much less freedom to pick up the phone and call their buddy Matt or Larry or Helen, or Dave and get that person to drop everything to deal with their latest money-making initiative. The fact that it cost the enterprise more and more every time they did this didn’t concern them—they didn’t care that costs racked up: testing to make sure changes didn’t affect anything else that was operational; creation of duplicate data and files, which often perpetuated bad data; and loss of integrated information with which to run the enterprise. And the fact that the company needed an army of “data cleansers” to prepare the reports needed for the government to meet its regulatory and Sarbanes–Oxley requirements wasn’t their concern.
2Everyone believed his or her needs were unique. Unfortunately, although he had Roman’s backing in theory, in practice Vince’s position was a bit unusual because he himself didn’t have an enterprise IT organization as yet and the DIOs’ first allegiance was clearly to their division presidents, despite having a “dotted line” reporting relationship to Vince. The result was that he had to choose his battles very, very carefully in order to lay the foundation for the future. First up was rede-signing the company’s internal computer infrastructure to use one set of standard technologies. Simplification and standardization involved a radical reduction of the number of suppliers and centralized procurement. The politics were fierce and painful with the various suppliers the company was using, simultaneously courting the DIOs and business unit leaders while trying to sell Vince on the merits of their brand of technology for the whole company. Matt Dawes had done everything he could to undermine this vision, making sure that the users caused the maximum fuss right up to Roman’s office. Finally, they’d had a showdown with Roman. “As far as I’m concerned, moving to standardized hardware and software is non-discussable,” Vince stated bluntly. “We can’t even begin to tackle the issues facing this company without it. And furthermore, we are in serious noncompliance with our software licensing agreements. We can’t even tell how many users we have!” This was a potentially serious legal issue that had to be dealt with. “I promised our suppliers that we would get this problem under control within eighteen months, and they’ve agreed to give us time to improve. We won’t have this opportunity again.” Roman nodded, effectively shutting down the argument. “I don’t really understand how more standardization is going to improve our business flexibility,” he’d growled, “but if you say so, let’s do it!” From that point on, Vince had moved steadily to consolidate his position, centralizing the purchasing budget; creating an enterprise architecture; establishing a standardized desktop and infrastructure; and putting tools, metrics, and policies in place to manage them and ensure the plan was respected by the divisions.Dawes and Larry Hughes, another DIO, had tried to sabotage him on this matter yet again by adopting another manufacturer’s customer relationship management (CRM) system (and yet another database), hoping that it could be up and running before Vince noticed. But Vince had moved swiftly to pull the plug on that one by refusing the project access to company hardware and giving the divisional structure yet another black mark. That episode had highlighted the need for a steering committee, one with teeth to make sure that no other rogue projects got implemented with “back door funding.” But the company’s entrepreneurial culture wasn’t ready for it, so again foundational work had to be done. “I’d have had a riot on my hands if I’d tried to do this in my first few years here,” Vince reflected as he walked back to his office, stopping to chat with some of the other executives on his way. Vince now knew everyone and was widely respected at this level because he understood their concerns and interests. Mainly, these were financial—delivering more IT for less cost. But as Vince moved around the organization, he stressed that IT decisions were first and foremost business decisions. He spoke to his col-leagues in business terms. “The company wants one consistent brand for its organization so it can cross-sell services. So why do we need different customer service organizations or back-end systems?” he would ask them. One by one he had brought the “C”-level executives around to at least thinking about the need for an enterprise IT organization. Vince had also taken advantage of his weekly meetings with Roman to demonstrate the critical linkage between IT and Roman’s vision for the enterprise. Vince’s motto was “IT must be very visible in this organization.” When he felt the political climate was right, he called all the “Cs” to a meeting. With Roman in the room for psychological support, he made his pitch. “We need to make all major IT decisions together as a business,” he said. “If we met monthly, we could determine what projects we need to launch in order to support the business and then allocate resources and budgets accordingly.” Phil Cooper, president of Internet Services, spoke up. “But what about our specificprojects? Won’t they get lost when they’re all mixed up with everyone else’s? How do we get funding for what we need to do?” Vince had a ready answer. “With a steering committee, we will do what’s best for the organization as a whole, not for one division at the expense of the others. The first thing we’re going to do is undertake a visioning exercise for what you all want our business to look like in three years, and then we’ll build the systems and IT infrastructure to support that vision.” Talking the language of business had been the right approach because no one wanted to get bogged down in techno-jargon. And this meeting had effectively turned the tide from a divisional focus to an enterprise one—at least as far as establishing a steer-ing committee went. Slowly, Vince had built up his enterprise IT organization, putting those senior IT managers reporting to him into each of the business divisions. “Your job is to participate in all business decisions, not just IT ones,” he stated. “There is nothing that happens in this company that doesn’t affect IT.” He and his staff had also “walked the talk” over the past two years, working with the business to identify opportunities for short-term improvements that really mattered a lot to the divisions. These types of quick wins demonstrated that he and his organization really cared about the business and made IT’s value much more visible. He also stressed accountability. “Centralized units are always seen to be overhead by the business,” he explained to his staff. “That’s why we must be accountable for everything we spend and our costs must be transparent. We also need to give the business some choices in what they spend. Although I won’t compromise on legal, safety, or health issues, we need to let them know where they can save money if they want. For example, even though they can’t choose not to back up their files, they can choose the amount of time it will take them to recover them.” But the problem of the DIOs had remained. Used to being kings of their own king-doms, everything they did appeared to be in direct opposition to Vince’s vision. And it was apparent that Roman was preaching “one company” but IT itself was not unified. Things had come to a head last year when Vince had started looking at outsourcing. Again the DIOs had resisted, seeing the move as one designed to take yet more power away from them. Vince had offered Helen a position as sourcing director, but she’d turned it down, seeing it as a demotion rather than a lateral move. The more the DIOs stonewalled Vince, the more determined he became to deal with them once and for all. “They’re undermining my credibility with the business and with our suppliers,” Vince had complained to himself. “There’s still so much more to do, and this divisional structure isn’t working for us.” That’s when he’d realized he had to act or RR wouldn’t be able to move ahead on its next project: a single customer service center shared by the four divisions instead of the multiple divisional and regional ones they had now. So Vince had called a meeting, ostensibly to sort out what would be outsourced and what wouldn’t. Then he’d dropped the bombshell. “They’ll get a good package,” he reassured himself. “And they’ll be happier somewhere else than always fighting with me.” The new IT organizational charts, creating a central IT function, had been drawn up, and the memo appointing his management team had been signed. Vince sighed. That had been a piece of cake compared to what he was going to be facing now. Was he ready for the next round in the “IT wars”? He was going to have to go head to head with the business, and it wouldn’t be pretty. Roman had supported him in getting the IT house in order, but would he be there for the next step? Vince looked gloomily at the reports the DIOs had prepared for their final meeting. They documented a complete data mess—even within the divisions. The next goal was to implement the single customer service center for all divisions, so a customer could call one place and get service for all RR products. This would be a major step forward in enabling the company to implement new products and services. If he could pull it off, all of the company’s support systems would, for the first time, talk to each other and share data. “We can’t have shared services without common data, and we can’t have good business intelligence either,” he muttered. Everything he needed to do next relied on this, but the business had seen it differently when he’d last tried to broach the subject with them. “These are our data, and these are our customers,” they’d said. “Don’t mess with them.” And he hadn’t ... . but that was then. Now it was essential to get their information in order. But what would he have to do to convince them and to make it happen?Discussion Questions1. List the advantages of a single customer service center for RR Communications. 2. Devise an implementation strategy that would guarantee the support of the divisional presidents for the shared customer service center.3. Is it possible to achieve an enterprise vision with a decentralized IT function?

What business and IT problems can be caused by lack of common information and an enterprise IM strategy?

What governance mechanisms need to be put in place to ensure common customer data and a shared customer service center?

What metrics might be useful?Mini Case from: Smith, H. A., and J. D. McKeen (2015). Mini Case “Shared Services at RR Communications.” In McKeen, J. D., & Smith, H. (2015). IT strategy: Issues and Practices (third edition) Boston: Pearson, pp. 178-181, #1-L07-1-002, Queen’s School of Business, reproduced by permission of Queen’s University, School of Business, Kingston, Ontario, Canada

The case study part 2 is from: Smith, H. A., and J. D. McKeen (2015). Mini Case “Enterprise Architecture at Nationstate Insurance.” In McKeen, J. D., & Smith, H. (2015). IT strategy: Issues and Practices (third edition) Boston: Pearson, pp. 1828-186, #1-L11-1-001, Queen’s School of Business, reproduced by permission of Queen’s University, School of Business, Kingston, Ontario, Canada
Mini Case: Enterprise Architecture at Nationstate Insurance Jane Denton looked around at her assembled senior IT leadership team waiting to hear what she was going to say. Most were leaning forward eagerly, though some appeared more cautious. They were a good team, she knew, and she wanted to lead them well. A seasoned CIO, with a whole career behind her in IT, Jane was the newly appointed global CIO of Nationstate Insurance. This would be her last job before retirement in three years and she wanted to find a way to make a lasting difference in this company. Nationstate was an excellent company—Jane had done her homework. It was one of the largest in the United States, with a worldwide presence in personal and commercial insurance, and had recently been voted one of Forbes’ “Best Big Companies.” It had good systems, good user–IT relationships, and good people. But the company aspired to be great and Jane wanted to help them by taking IT to the next level. She knew that the world was changing—largely as a result of technology—and she knew that IT and its traditional approach to systems development was also going to have to change. “Our IT function needs to become more cutting edge in adopting emerging technologies,” she had told the CEO shortly after she was hired, “and we need to become more flexible and agile in our approach to development work.” Now she had this time and this team to accomplish her goals. However, it was much easier said than done. Like almost every large organization, Nationstate had a hodgepodge of different systems, data, and processes—most serving just one of its six business units (BUs). Nationstate’s decentralized structure had served it well in the past by enabling individual BUs to respond quickly to changing market needs but a couple of years before Jane’s arrival, recognizing the need for some enterprise thinking, the CEO had created a federated structure with some centralized functions, including parts of IT. So some of IT was now centralized and shared by all the BUs (e.g., operations) and reported directly to Jane, while the rest (e.g., system development) was decentralized. Each BU had its own CIO and IT staff who reported jointly to the BU’s president and to Jane. This potentially unwieldy structure was made more palatable by the fact that the business unit CIOs had great business knowledge and were well trusted by their presidents. In fact, it was central IT that was often seen as the roadblock by the BUs. She had never led an IT organization like it, she reflected, and in her first few months, she had made a considerable effort to understand the strengths and weaknesses of this model and how responsibilities had been divided between centralized enterprise services and the decentralized IT groups (each quite large themselves) in the business units.Now she thought she had a good enough handle on these that she could begin work with her senior leadership team (the BU CIOs) to develop a plan to transform IT into the kind of technology function Nationstate would need in the years to come. “I know you are both enthusiastic and apprehensive about transformation,” she said. “We have a great organization and no one wants to lose that. We need to be responsive to our business needs but we also need to incorporate new development techniques into our work, do a better job with emerging technologies, and begin to rationalize our application and technology portfolios. We have duplicate systems, data and software all over the place. Our CEO and the BU Presidents want to see us use our technology resources more efficiently, but more than that, they want our leadership in using technology effectively for the organization as a whole. We can’t do this if we’re all working in separate silos.” Heads began nodding around the room as she continued. “At present, every business unit has its own IT architecture and architects and each of you believe you are making the ‘right’ technology decisions but you are all doing it differently.” The head nodding stopped and a mood of wariness took over. “No one in our organization has the big picture of what we have and where we need to go. We have to learn what makes sense for us to do at an enterprise level and what’s best left in the business units. Architecting our technology, information, business and applications properly is the key to doing it right.” “What exactly are you proposing?” asked Owen Merton, CIO of the Casualty Division. “I think you’re right that we need an enterprise architecture, but I don’t want to lose the good work we’ve done at the BU level.” “Well, I really want to centralize all architecture,” said Jane. “I think that’s what works best in other organizations and that’s going to be the most effective way to make it work here. BUT . . .” she added, “I’d
2like to speak with each of you individually and with your senior architects before I do. I’m open to your ideas as long as they address the needs that I’ve just outlined.” Over the next two weeks, Jane listened carefully to what the divisional CIOs had to say. They all agreed with Merton that the relationships with the BUs were extremely important and centralizing architecture had to be done carefully. All of them had heard horror stories about the “architecture police” in other companies—hard-line techies who set standards and created blueprints and insisted on them being followed in spite of the difficulties their policies caused for the business. “Architecture can’t live in an ivory tower,” explained Vic Toregas, CIO of Claims. “It has to be rooted in the reality of our business and it can’t be seen to slow things down.” Jane agreed. “We must make sure that our architecture function is designed and managed to ensure rapid delivery to the business.” On the other hand, Nick Vargo, CIO of Group Health, was concerned that without a strong enforcement mechanism, standards wouldn’t be followed. “What’s the point of having standards if we don’t enforce them?” he asked. Jane’s head whirled. It wasn’t going to be easy to strike the right balance between developing a good, sustainable process that would provide a blueprint for where the company needed to go and enable the company to build the common capabilities it would need for the future, while delivering solutions quickly and flexibly for the BUs. “What we don’t need is a ‘Winchester Mystery House’,” she reflected, recalling the famous local house whose owners kept adding to it over many years with no overall plan.She became more worried when she began to speak with the BU architects, with an eye to appointing one of them as her chief enterprise architect. They seemed to be technically competent but were not what she would call “relationship people” or business strategists. The job, as she envisioned it, would combine strong leadership skills, a good understanding of the business, and excellent communication skills to translate why the business should care about architecture, with strong technical skills. Her day became a bit brighter when she began her final interview with Seamus O’Malley, the senior architecture manager of the commercial BU. As they spoke, Jane was impressed with his vision and pragmatism, as well as his strong communication skills. By the end of the hour she knew she had found her new chief enterprise architect. “I’d like you to take this new job,” she told him. “I think you are the right person to ensure we have the standards, tools and practices in place to develop a common architecture for Nationstate.” Seamus thought for a moment before replying. It was a great offer but he had his doubts that Jane’s plan would work and this situation had to be carefully handled. “Thank you for your faith in me,” he began diplomatically, “but I would like to suggest a slight modification to your plan. You see, I’ve been an architect in centralized organizations and there has always been an ‘us versus them’ mentality between the architecture group and both the rest of IT and the business units.” Jane recalled the horror stories of the “architecture police.” “So what I’d like to propose is a com-promise. I would become Chief Enterprise Architect but I would also remain Senior Architecture for Commercial and involve the other BU Senior Architects in creating a strong enterprise architecture that works for us all. That way, no one will see me as just ‘the enterprise guy’ and whatever standards we set and decisions we make centrally will affect me in Commercial, just like they’ll affect all the other BUs. When the other business units see that I’m willing to eat my own dog food, I think they’ll be more ready to accept the standards and changes we’ll be introducing.” While not sure the compromise would work, Jane agreed to try it for a year and Seamus set out to build a centralized architecture function from scratch. With the authority given to him by Jane, all of the BU senior architects now had a dual reporting relationship—to their CIO and to him as the chief architect. At their first weekly meeting with the BU senior architects, Seamus outlined his role and agenda. “As you know, each of us has been individually responsible for developing an effective IT architecture for our business units but we haven’t done any coordination between them. That is no longer good enough for our business needs and I, with your help, have been given the job of establishing an enterprise architecture that will create an enterprise technology blueprint for Nationstate, which we will all have to follow in the business units. I want to work collaboratively with you so that we come up with a plan and processes that will work for each of us in the business units, as well as for the enterprise as a whole. We will need to build our enterprise architecture slowly but steadily so that people will trust us, and that means having good governance, good processes and a collaborative approach to this work,” he stated. “Our first priority is building strong relationships with both Jane and the other CIOs and our BU Presidents. Enterprise Architecture sits in the middle between these groups, so good relationships are essential.” “However,” he continued. “We are going to need a way to establish and enforce standards—enterprise ones, not the ones you have now—and this is going to be difficult to explain.“I’ll say,” remarked Sarah Jensen, the senior architecture manager from Personal Insurance. “What do we say when the business asks why they can’t do something that’s important to them because our ‘standards’ won’t let them?” “That’s a good question Sarah,” said Seamus. “And it gets right to the heart of why architecture is important. We need to present architecture in ways that are easy for the business to understand, without scaring or threatening them. For example, we need an application reduction strategy designed to eliminate duplication, reduce complexity and save money. The business already understands the pain of having to jump from system to system and knows that owning two cars is more expensive than one. If we explain it to them in this way, they will understand the advantages of having a single system and a single workflow.” “But isn’t good architecture about more than cost savings?” asked Michael Lee, senior architecture manager from Claims. “We need to develop a foundation of com-mon information, tools and processes so that we’re not reinventing the wheel going into the future. And someone needs to decide what new technologies we’re going to need and where we’re going to use them. There are so many new applications and devices coming out every day now, we’re going to be in a real mess if we don’t do this properly.” “You’re exactly right,” said Seamus. “These things do have to be managed for the good of the enterprise—both to make it more effective and more efficient. But it’s how we manage them that’s important. If we put lots of bureaucracy in place and don’t add value, no one is going to support us and they’ll find ways to undermine what we are trying to do. We can’t take a ‘field of dreams’ approach to architecture. We need to attach our work to real business value and real projects. Once our leaders understand this, we’ll get their support.” “So here’s our challenge,” Seamus told his assembled team a few minutes later.“We need to design an Enterprise Architecture function that does all these things. It’s got to be a process that comes up with the standards and guidelines that each of you can live with and support in the BUs. And, as you know, I myself will have to live with them in Commercial as well.” “Here’s what I believe we need to accomplish as soon as possible,” he stated, flashing a PowerPoint slide on the screen:

1. An enterprise governance process to set architecture strategy, policies and standards for technology, applications, and information that reflects the federated structure in the organization.

2. A means of monitoring that all new projects comply with the agreed-upon architecture while ensuring that this process doesn’t present an obstacle to getting IT projects completed quickly.

3. A process for allowing “variances” to the current standards, if necessary, and a way to manage them back to the agreed-on standards.

4. A means of identifying important new IT capabilities and services that should be shared by the enterprise.

5. A means of evaluating emerging new technologies and setting standards for them.

6. Identifying roles and responsibilities for the enterprise architecture function and the LOB architecture functions.

7. Developing a means of incorporating feedback and continuous improvement into our work.“I want to blend and weave our work into the architecture teams we already have in the business units as much as possible,” Seamus concluded. “This will keep us close to business needs and enable us to get enterprise value from the teams we have in place. And I don’t want to add any more process than we need to at an enterprise level. For example, if the Claims group needs a new technology, their architecture group could do the preliminary evaluation and make recommendations for what we should do. But we need to ensure that the resulting decision is a good one for the entire enterprise.”
I’ve got to report back to Jane in a month, so I’d like you to think about what might and might not work for your division and for us as an enterprise. I’ve scheduled a couple of working sessions for us over the next two weeks so we can hash this out. We have an exciting opportunity to take IT to the next level at Nationstate if we do this right, so let’s not mess this up.

”Discussion Questions

1. List and describe all of the potential benefits (and costs) that Nationstate would realize from the establishment of an enterprisewide architecture as envisioned by Jane Denton?

2. Build a business case for Seamus O’Malley to present to the senior management team at Nationstate in order to get their buy-in. In addition to benefits and costs, the business case must answer the “what’s in it for me” question that the BU 3presidents all have.

3. Seamus O’Malley is rightfully worried about governance (i.e., making sure that the enterprise architectural standards are adopted by all BUs). Both he and Jane are wary of forced compliance because such measures lead to “architecture police.” What governance procedures could they put in place that would win “hearts and minds”; that is, BU architects would comply with the enterprise architecture standards because they believe in them—not because they are forced to comply with them?

This Management Assignment has been solved by our Management experts at My Uni Paper. Our Assignment Writing Experts are efficient to provide a fresh solution to this question. We are serving more than 10000+ Students in Australia, UK & US by helping them to score HD in their academics. Our Experts are well trained to follow all marking rubrics & referencing style.
Be it a used or new solution, the quality of the work submitted by our assignment experts remains unhampered. You may continue to expect the same or even better quality with the used and new assignment solution files respectively. There’s one thing to be noticed that you could choose one between the two and acquire an HD either way. You could choose a new assignment solution file to get yourself an exclusive, plagiarism (with free Turnitin file), expert quality assignment or order an old solution file that was considered worthy of the highest distinction.