Jim Nasyum was vey furious and close to exploding. No wonder. It was because Jim just...

Transcribed Image Text:

Jim Nasyum was vey furious and close to exploding. No wonder. It was because Jim just learned that Copernicus, a major project he was overseeing, might be two months late. It was supposed to be a six-month project. Jim was a senior software engineer of Jtronics. He was responsible for the development of software for extracting information from the measurement equipment developed by the company. Jim heard this bad news from the man who ran the project, Ide Home. In fact, Ide is Jim's star project manager. The sheer consequences of this delay terrified Jim and he already visualized the face of the easy-go-ballistic vice-president when she hears about Copernicus' delay. It is going to halt the release of four new product lines that are planned to use the Copernicus software, which Jtronics nationally advertised. More than anything else, Jim was furious because of Ide's explanations about the causes of the delay. Ide explained that they had problems with change management software which caused several losses of data and information. "This is not the first time that we have had problems with this software," Jim thought. Jim had to deal with the delay before the news reached the vice-president. Jtronics Jtronics is a U.S. company, ranking as a number two in market share in the electronic testing and measurement equipment industries. The company has buyers in both conventional and technology industries; and enjoys sales of more than $1 billion. More than half of that amount comes from foreign markets. Almost all products are software rich, causing the company to pay serious attention to software development, treating the software component on par with the hardware. Each of its new product development projects, organized by means of programs, has software and hardware managers all reporting directly to the program manager. Changes in the Software Development Project As in all software development projects, there are always changes that occur during development, and many revisions are made to the software. To manage these changes, Jtronics uses change request management software called Shadow (see Figure 10.1). Shadow allows users to submit defect or bug reports through emails using an array of report templates and metrics, and any changes or resolutions made are reported back to the team. The Shadow is coupled with software called ClearCase, which is versioning software that maintains the versions of the software under development. Figure 10.1 The Flowchart of the Process of Using Shadow The defect may be postponed; to be fixed in later release Defect found and submitted to Shadow Defect is flagged as "new" Project manager assigns defect to an engineer The engineer is working on the defect Defect is Tesolved Defect has been fixed and the fix has been verified to work Defect is determined to be a duplicate; it already exists in a previous record Shadow and ClearCase have been used for several years by Jtronics, and since then users of the tools from different departments throughout the company have filed many complaints and recommendations to improve the software, as they feel that it does not fit their needs. The users prefer a system that can expedite the whole process of bug submission and change request. Most users complain that the tool is too complex; that the process is too tedious and takes a lot of time to complete the request. No immediate actions are taken to these inputs. Jim has noticed that there has been a backlog of complaints on the current change management software. According to Jim, if every engineer can save 30 seconds off of the process, the total savings for the company would be $4 million each year. Now, with the visibility of Copernicus problems, Jim hoped it was going to be easier to build the caseto improve change management software. However, he also knew that he had to do something to prevent fiasco related to the Copernicus delay. Change Management at Jtronics Jtronics has some formal guidelines for managing changes in the organization, specifically for implementing new systems. For example, when considering implementing a new system, a business case must be presented and discussed with a committee; a person is appointed in charge of the change; the details of the change (reason, description, etc.) are documented in a change report form, and the document is signed off by the committee; then the change is approved. The process or procedure may differ a little, depending on the type and/or scope of the change. However, only the formal process is provided with a guideline, while the informal processes (such as getting buy-in from the stakeholders)which sometimes are important to the change's success are not described. Jim realized the importance of marketing the change, and getting stakeholders buy-in. Getting Buy-In: Communication Jim recognized that it was necessary to get everybody to buy-in-both management and technicians on the floor. In order to do that, Jim created a sort of network of the stakeholders. Actually, he drew a kind of interrelationship diagraph, as it is known in quality business (see Figure 10.2). He started with a node that represents him, and then he created a node for every person he has direct connection to and drew a line that connects his node with that person's node. On the line, he wrote down what is his contribution to that person, and vice versa. Then, if that person had a direct connection to another person, either the ones he had direct connection to, or the ones he did not have, and did the same with the edges and contributions. This way he can see who and where the stakeholders are, and what their relationship is with him and to others. He can also see who he should contact to reach a person whom he does not have a direct connection to. He then was able to strategically communicate his idea to get buy-in from the stakeholders. Figure 10.2 Jim's Interrelationship Diagraph Accomplish Portfolio Kelly's Productivity Increase Project Team Projects Technical Support VP Kelly Funding Sponsorship Jim Support Sponsorship Engineer's Technicians of Easier Dept1 Make Life Support Tools Resources Support Company Strategy Ease 'Pain' for and Support Projects Portfolio Sponsorship Engineering Accomplish Portfolio Project Team Manager of VP Dept1 of Funding Sponsorship Dept1 Jim started off by going back to his camp-people in favor of improving the change management software. He had the direct contact with them. From them, he found out what they liked about the current system; what they didn't like about it; and what they would like the change management software to be. For instance, he found that Shadow uses 127 different forms to report different kinds of bugs and defects, and the users find it cumbersome making the whole process an additional burden to their already over-swamped workday. Since Jim understood that Shadow was used company-wide, and any changes to the system would affect the whole company, he shared his concern with his manager, Kelly Braid, with whom he also had direct contact. Kelly understood the issue with Shadow and supported Jim's initiative to take action on the matter. They worked together to create a business case and identified the alternative solutions. Mainly, they considered two optionsfixing the system or buying new software from a third-party vendor. Based on the requirements gathered from the users so far, they found that a third-party vendor software called ClearQuest met their needs. Kelly and Jim started introducing ClearQuest to the technicians and engineers. All agreed that it was a better alternative. Buying ClearQuest will cost about $500,000. At Jtronics, a project with such value requires approval from the executive management at the CEO level. Jim realized that in order to get funding for the project, he had to have buy-in from the vice-president to get approval. Unfortunately, Jim lacked direct connection to the VP of his department. But Kelly had this direct connection. So Jim and Kelly worked on developing a business case that was clear and understandable for the VP. With regard to this, in one of the meetings, Jim commented, "It was cool- everybody already understood the issue, and the engineering managers were able to convince their VPs, while my VP already understood the issue because my boss and I already explained it to him beforehand." Afterward, it was just a quick and easy discussion between the VPs to decide whether or not this project was worth funding. Speed Bumps Finally, they agreed that the project had a valid business case, and deserved a "go." However, Jtronics was going through some changes at the time including shifting of management and other financial challenges. The new management was more interested in projects that are aimed toward saving money, and a half-million-dollar project such as changing Shadow to ClearQuest was not exactly attractive. Also, with Jtronics' financial situation at the time, Jim's project was placed under low priority and it went under the radar for years. Later, Rational Software, the company that developed ClearQuest, was bought by IBM. After the acquisition, IBM reviewed all the projects done by Rational and noticed the project with Jtronics, which had been delayed for quite some time. They decided to follow-up, and contacted Jim. They offered help to proceed with the project by giving Jtronics a discount of $150,000. Jim was ecstatic and proposed the project back to his new manager. And sure enough, the project finally received the green light it had been waiting for. Implementation Although most of the users understood and accepted the change, Jim was aware that the switch was not going to be simple. First of all, the users who were receiving the change are technicians and engineers. Since Jtronics is a company that relies on the productivity of its crews, a system change like this is likely to cause a lot of down time while getting used to the new system. To overcome this, Jim and his team customized the "look and feel" of the ClearQuest interface so it closely resembled Shadow. Besides the common functions, they also included some of the new features of ClearQuest to the interface. This way, the users were able to quickly grasp the new tool because it was familiar to them, and it only required one or two hours for training. In the meantime, users gave feedback (comments, recommendations, bug reports, etc.) to Jim's team to improve the functionality of the tool. Secondly, not everybody was ready for a change. There were some users who were eager for the change. They surprised Jim by stopping by his office and telling him directly that they wanted to use the tool immediately. There were also users who were not ready for the tool; either they were busy with their project at the time and could not spare enough time for learning the new tool, or they simply did not see the value of it. Jim described this situation as analogous to the technology adoption life cycle, where there are users who are enthusiastic about the new technology and cannot wait to start using it (early adopters), and there are users who do not adopt the technology until late in the life cycle (late adopters/laggards). Jim devised a queuing strategy for adoption. Users who were ready (and eager) to change, were placed in the front of the queue, while the late adopters were later. This way, the training was done in several sequences, one group at a time (each group consisted of one or more different departments). Copernicus' Fate By the way, as mentioned earlier, Jim had to do something to prevent a possible fiasco related to the Copernicus delay. And, he did. He took two major actions. First, he approved Copernicus to outsource their quality testing, do it overnight, and save two months' time. Second, he added to the team three full-time programmers to speed up the coding work. Jim knew the dangers of Brook's law (adding people to a late project will make it later). With all these, the Copernicus was well on its way, and Jtronics was more prepared than ever to proceed with their release of the next four new product lines, and their future projects. 1. How important is communication to a successful change management project? Propose a strategy for effective communication. 2. What should be a strategy to address the organization's members who are reluctant to change? Jim Nasyum was vey furious and close to exploding. No wonder. It was because Jim just learned that Copernicus, a major project he was overseeing, might be two months late. It was supposed to be a six-month project. Jim was a senior software engineer of Jtronics. He was responsible for the development of software for extracting information from the measurement equipment developed by the company. Jim heard this bad news from the man who ran the project, Ide Home. In fact, Ide is Jim's star project manager. The sheer consequences of this delay terrified Jim and he already visualized the face of the easy-go-ballistic vice-president when she hears about Copernicus' delay. It is going to halt the release of four new product lines that are planned to use the Copernicus software, which Jtronics nationally advertised. More than anything else, Jim was furious because of Ide's explanations about the causes of the delay. Ide explained that they had problems with change management software which caused several losses of data and information. "This is not the first time that we have had problems with this software," Jim thought. Jim had to deal with the delay before the news reached the vice-president. Jtronics Jtronics is a U.S. company, ranking as a number two in market share in the electronic testing and measurement equipment industries. The company has buyers in both conventional and technology industries; and enjoys sales of more than $1 billion. More than half of that amount comes from foreign markets. Almost all products are software rich, causing the company to pay serious attention to software development, treating the software component on par with the hardware. Each of its new product development projects, organized by means of programs, has software and hardware managers all reporting directly to the program manager. Changes in the Software Development Project As in all software development projects, there are always changes that occur during development, and many revisions are made to the software. To manage these changes, Jtronics uses change request management software called Shadow (see Figure 10.1). Shadow allows users to submit defect or bug reports through emails using an array of report templates and metrics, and any changes or resolutions made are reported back to the team. The Shadow is coupled with software called ClearCase, which is versioning software that maintains the versions of the software under development. Figure 10.1 The Flowchart of the Process of Using Shadow The defect may be postponed; to be fixed in later release Defect found and submitted to Shadow Defect is flagged as "new" Project manager assigns defect to an engineer The engineer is working on the defect Defect is Tesolved Defect has been fixed and the fix has been verified to work Defect is determined to be a duplicate; it already exists in a previous record Shadow and ClearCase have been used for several years by Jtronics, and since then users of the tools from different departments throughout the company have filed many complaints and recommendations to improve the software, as they feel that it does not fit their needs. The users prefer a system that can expedite the whole process of bug submission and change request. Most users complain that the tool is too complex; that the process is too tedious and takes a lot of time to complete the request. No immediate actions are taken to these inputs. Jim has noticed that there has been a backlog of complaints on the current change management software. According to Jim, if every engineer can save 30 seconds off of the process, the total savings for the company would be $4 million each year. Now, with the visibility of Copernicus problems, Jim hoped it was going to be easier to build the caseto improve change management software. However, he also knew that he had to do something to prevent fiasco related to the Copernicus delay. Change Management at Jtronics Jtronics has some formal guidelines for managing changes in the organization, specifically for implementing new systems. For example, when considering implementing a new system, a business case must be presented and discussed with a committee; a person is appointed in charge of the change; the details of the change (reason, description, etc.) are documented in a change report form, and the document is signed off by the committee; then the change is approved. The process or procedure may differ a little, depending on the type and/or scope of the change. However, only the formal process is provided with a guideline, while the informal processes (such as getting buy-in from the stakeholders)which sometimes are important to the change's success are not described. Jim realized the importance of marketing the change, and getting stakeholders buy-in. Getting Buy-In: Communication Jim recognized that it was necessary to get everybody to buy-in-both management and technicians on the floor. In order to do that, Jim created a sort of network of the stakeholders. Actually, he drew a kind of interrelationship diagraph, as it is known in quality business (see Figure 10.2). He started with a node that represents him, and then he created a node for every person he has direct connection to and drew a line that connects his node with that person's node. On the line, he wrote down what is his contribution to that person, and vice versa. Then, if that person had a direct connection to another person, either the ones he had direct connection to, or the ones he did not have, and did the same with the edges and contributions. This way he can see who and where the stakeholders are, and what their relationship is with him and to others. He can also see who he should contact to reach a person whom he does not have a direct connection to. He then was able to strategically communicate his idea to get buy-in from the stakeholders. Figure 10.2 Jim's Interrelationship Diagraph Accomplish Portfolio Kelly's Productivity Increase Project Team Projects Technical Support VP Kelly Funding Sponsorship Jim Support Sponsorship Engineer's Technicians of Easier Dept1 Make Life Support Tools Resources Support Company Strategy Ease 'Pain' for and Support Projects Portfolio Sponsorship Engineering Accomplish Portfolio Project Team Manager of VP Dept1 of Funding Sponsorship Dept1 Jim started off by going back to his camp-people in favor of improving the change management software. He had the direct contact with them. From them, he found out what they liked about the current system; what they didn't like about it; and what they would like the change management software to be. For instance, he found that Shadow uses 127 different forms to report different kinds of bugs and defects, and the users find it cumbersome making the whole process an additional burden to their already over-swamped workday. Since Jim understood that Shadow was used company-wide, and any changes to the system would affect the whole company, he shared his concern with his manager, Kelly Braid, with whom he also had direct contact. Kelly understood the issue with Shadow and supported Jim's initiative to take action on the matter. They worked together to create a business case and identified the alternative solutions. Mainly, they considered two optionsfixing the system or buying new software from a third-party vendor. Based on the requirements gathered from the users so far, they found that a third-party vendor software called ClearQuest met their needs. Kelly and Jim started introducing ClearQuest to the technicians and engineers. All agreed that it was a better alternative. Buying ClearQuest will cost about $500,000. At Jtronics, a project with such value requires approval from the executive management at the CEO level. Jim realized that in order to get funding for the project, he had to have buy-in from the vice-president to get approval. Unfortunately, Jim lacked direct connection to the VP of his department. But Kelly had this direct connection. So Jim and Kelly worked on developing a business case that was clear and understandable for the VP. With regard to this, in one of the meetings, Jim commented, "It was cool- everybody already understood the issue, and the engineering managers were able to convince their VPs, while my VP already understood the issue because my boss and I already explained it to him beforehand." Afterward, it was just a quick and easy discussion between the VPs to decide whether or not this project was worth funding. Speed Bumps Finally, they agreed that the project had a valid business case, and deserved a "go." However, Jtronics was going through some changes at the time including shifting of management and other financial challenges. The new management was more interested in projects that are aimed toward saving money, and a half-million-dollar project such as changing Shadow to ClearQuest was not exactly attractive. Also, with Jtronics' financial situation at the time, Jim's project was placed under low priority and it went under the radar for years. Later, Rational Software, the company that developed ClearQuest, was bought by IBM. After the acquisition, IBM reviewed all the projects done by Rational and noticed the project with Jtronics, which had been delayed for quite some time. They decided to follow-up, and contacted Jim. They offered help to proceed with the project by giving Jtronics a discount of $150,000. Jim was ecstatic and proposed the project back to his new manager. And sure enough, the project finally received the green light it had been waiting for. Implementation Although most of the users understood and accepted the change, Jim was aware that the switch was not going to be simple. First of all, the users who were receiving the change are technicians and engineers. Since Jtronics is a company that relies on the productivity of its crews, a system change like this is likely to cause a lot of down time while getting used to the new system. To overcome this, Jim and his team customized the "look and feel" of the ClearQuest interface so it closely resembled Shadow. Besides the common functions, they also included some of the new features of ClearQuest to the interface. This way, the users were able to quickly grasp the new tool because it was familiar to them, and it only required one or two hours for training. In the meantime, users gave feedback (comments, recommendations, bug reports, etc.) to Jim's team to improve the functionality of the tool. Secondly, not everybody was ready for a change. There were some users who were eager for the change. They surprised Jim by stopping by his office and telling him directly that they wanted to use the tool immediately. There were also users who were not ready for the tool; either they were busy with their project at the time and could not spare enough time for learning the new tool, or they simply did not see the value of it. Jim described this situation as analogous to the technology adoption life cycle, where there are users who are enthusiastic about the new technology and cannot wait to start using it (early adopters), and there are users who do not adopt the technology until late in the life cycle (late adopters/laggards). Jim devised a queuing strategy for adoption. Users who were ready (and eager) to change, were placed in the front of the queue, while the late adopters were later. This way, the training was done in several sequences, one group at a time (each group consisted of one or more different departments). Copernicus' Fate By the way, as mentioned earlier, Jim had to do something to prevent a possible fiasco related to the Copernicus delay. And, he did. He took two major actions. First, he approved Copernicus to outsource their quality testing, do it overnight, and save two months' time. Second, he added to the team three full-time programmers to speed up the coding work. Jim knew the dangers of Brook's law (adding people to a late project will make it later). With all these, the Copernicus was well on its way, and Jtronics was more prepared than ever to proceed with their release of the next four new product lines, and their future projects. 1. How important is communication to a successful change management project? Propose a strategy for effective communication. 2. What should be a strategy to address the organization's members who are reluctant to change?