Frustrations of Information System Professionals
Last semester, my group was tasked to make an Information System Needs Assessment (ISNA) for a certain company as part of our requirement for the subject MIS 1. We assessed our adopted company’s current information system by conducting SWOT and STEEP analysis and provided some recommendation for their needs based on our assessment. From that experience, I concluded that establishing an information system plan is a very tedious and crucial job. It is tedious because the IS professional in-charge have to take a lot of things into considerations before making any changes in the information system infrastructure of that organization. It is a crucial job because the information system implementation would normally involve certain vital resources such as money and properties that are critical resources and should be allocated well. Basically, I can say that the information system of a company will serve as a vital investment. Just like any investment, there is always a possibility of failure especially if not planned well which will cause the organization to waste important resources and would normally mean lose financial resources. Because of this, it is expected that most IS professionals usually develop some frustrations from developing an information system plan because of the problems that they encounter.
Based on our previous discussions concerning the importance of Planning, I already learned that planning is a very crucial part of developing any kind of system. Planning is also an important part in the business process because it will describe the organization’s direction and the steps that the organization would take in order to get there. Just as what I discussed on my previous entries in my blog, an information system plan (ISP) is basically a plan concentrated on aligning the information systems of an organization to its business plan as a whole. An information system is comprised of the hardware, software and peopleware of an organization. Usually, the term information system is related to using technology as a crucial part of an organization. The term is also used to identify the computer-based system that an organization is using. In addition, an IS plan is just a part of the overall business plan of an organization. The IS plan of the organization must align with the business plan and must conform to the overall vision of an organization.
Since I’m still a student and my experience in developing an IS plan is still rudimentary, an expert opinion would help in the enlightenment of this topic. An information system professional is someone who is considered an expert and should have the experience in developing an information system plan for an organization that range from simple to complicated systems. Together with my classmates, we interviewed the MIS supervisor of Samulco for this assignment.
Based on the interview that we had with the MIS supervisor of Samulco, he identified the two most frequently experienced causes of frustration of IS professional like him and the end users while working on an IS plan.
In terms of Information System planning, there are some common problems that IS professionals encounter while working on an IS plan. Based on our interview with the MIS supervisor of Samulco last Monday (December 7) , he identified two of the most frequently experienced causes of frustrations of IS professionals like him. The first cause of frustration in IS planning that he mentioned is Budget Constraint. He said because of budget constraint, many problems arise from that problem alone. Because of budget constraint he said, there would be lack of manpower and lack of support. He cited a scenario where if the company wants a specific kind of system, but they don’t want to buy the necessary hardware for the job. This kind of problem would normally become a source of frustration of the Information System Planner. The IS planner should find a way to get what the client wants but in lesser price which in reality is a very frustrating thing to do. Another scenario that he cited is if you as a supervisor need at least three programmers but the company could only provide you with two because of budget constraint again, then that could also be a problem because it would be very hard to finish the necessary project in the allotted time if there is less manpower available for the job.
For most businesses, the requirements on the computing side at least should include:
* Hardware; the actual computers and servers.
* Software; programs and operating systems.
* Phone lines.
* Internet systems.
* Computing consumables and peripherals.
*Information Technology Support.
* Computer training, if needed, for staff.
The amount of technological requirements needed by a business will again depend on the size and type of business. This is by no means an extensive list and all companies will be different, but this does represent at least the basic technology requirements. The budget may increase or decrease depending on the sophistication of the equipment and the software needed.
Another issue that concerns budgetary factor is the decision whether to lease or buy technology. In the long run it may seem like buying is the less expensive option, but leasing is usually the cheaper option when repairs and upgrading technology are factored in. Most small businesses should take the leasing option in order to save on the capital outlay that comes with buying, and upgrading new technology.
Marc Berthiaume cited some important considerations that a company should put in mind when planning for an IT budget.
According to Berthiaume’s article, the following are some step-by-step guidelines to follow when planning your IT budget:
1. Calculate your technology costs from the previous year. Unless you are planning major changes in your IT strategy, this will give you a range to work with.
2. Most companies plan for moderate growth. These companies should set up a category for IT maintenance/support and one for new technology expenditures. (Companies should first calculate maintenance/support of existing equipment, since this number will remain approximately the same as the previous year.)
3. If you plan to purchase new systems or services, you should calculate the cost of the technology and then budget for installation and maintenance_ Depending on complexity, you also may want to budget for testing and downtime. Get estimates and make sure to pad this cost in case things take longer to install than originally expected.
4. Once you've calculated standard IT purchases and maintenance costs for the year, create a separate budget line for technology development--this is for longer-term IT planning, including new IT projects or major system upgrades.
5. Err on the conservative side and consider the possibility of leasing and outsourcing when faced with costly technology expenditures.
From those tips that I have cited from authors above, I can say that budgeting itself for an Information system (which already includes IT) is such a tedious task. Aside from the tips mentioned by article writers above, the IS planner could also develop his or her own standards on planning for the Information system based on the budget that he or she is given.
In my opinion, I do believe that budget constraint can be a real source of frustration from the IS planner’s part while working on an IS plan. The “budget” in a plan is the main means of resource to keep the system going. Without the necessary budget, it would be hard if not impossible to make the necessary activities/steps or improvements to implement the planning process as well as the implementation of the plan itself. If the necessary budget is not supplied, then it is expected that the project would require a longer time to be implemented or the output of the project itself would be not satisfying or worse would turn out to be a failure. As I mentioned above, one of the after effect of having a budget constraint is lack of manpower. From this problem alone, another problem can arise which is the extension of deadline. This problem usually arises because of the lack of manpower that would support the whole information system plan. The limited number of manpower will require a lot more time to finish a certain project compared to having more manpower to work on a certain project. If there is an extension of the deadline, another set of budget is now required to suffice the resources needed in finishing the project thus making the development of a project more costly than what was previously planned. This problem is one of the possibilities that an information system planner usually encounter that came from the budget constraint. The MIS supervisor also mentioned that budget constraint can also produce lack of support. The way I understand it, the lack of support that he means is the lack of support for the product by the top management because of the higher cost of purchasing the necessary requirements for an information system. This kind of problem could frustrate the IS planner because he or she will be restricted on the kind of information system that he wants to implement for the company.
Budget constraint is considered a frustration because of the fact that IS planners can’t do anything to make the budget bigger than what an organization can offer. It is a top management decision on how much is allocated on putting up an information system plan for their company. All the information system planner can do is make the most of what he is given and make the best plan out of the budget that was allocated for a project despite the constraint. Making a realistic technology budget will involve time and research. A long term technology budget is essential for the smooth running of any kind of business that gives importance and emphasis to technology.
The second cause of frustration among IS Planners would be the user’s resistance to a new system. He said that when you develop a system, then when it comes to the actual implementation, the end users tend to resist in using the system that you created. When we asked him, how do they solve or manage the user resistance of their system, he said that they don’t do anything at all. He said that you cannot really force someone to like your system. He said that if the user fervently denies using your system, then you could do nothing unless some big guy from the upper level would force them to use the system that you created. He also agreed when one of my co-interviewer told him (based from one of our discussions on Software Engineering), that user resistance is considered a failure of project. He added that you committed the mistake during the analysis phase when you didn’t anticipate what the end users’ reaction would be. This could happen if you didn’t planned/analyze thoroughly what the users really need and wanted the system to be. Obviously, when it comes to the user’s point of view, this could be also a source of frustration when the users are not inclined or comfortable on using the new system that the developers created.
According to the research paper made by Shari Shang and Tim Su entitled “Managing User Resistance in Enterprise Systems Implementation”, user resistance indicates a gap between change initiators and employees who try to maintain their status quo with undesirable behaviors toward change (Coch and French, 1948; Davison, 1994). Such undesirable behaviors of workers are a response to management-imposed changes in job and work methods (Piderit, 2000). Many researchers (Ginzberg, 1975; Jiang, 2000, Joshi, 1991; Keen, 1981; Kotter and Schlesinger, 1979; Markus, 1983) have identified reasons for user resistance. These reasons include loss of power, increased work, low tolerance, lack of trust and so forth. Similar circumstances can also be found with wide-scoped ES implementation. Many strategies have been suggested to manage user resistance; these strategies range from user participation, job redefinition, to some forceful actions. However, the most common mistake managers can make would be to follow only one approach or a limited set of strategies regardless of the situation.
Among the reasons for resistance that have been observed in various enterprise systems cases in the said study is the parochial self-interest which is the resistance to change to prevent losing something of value. Its contents include losing power and status; reduced scope for advancement or job security and loss of autonomy and control or specific skills. Another reason is misunderstanding and lack of trust or the misconceptions about the implications and insufficient information of the benefit and gains. Examples of this are misunderstanding the implementation of change and insufficient knowledge in using the new systems. Another reason for user resistance would be the different assessment where employees see more cost that benefits and those initiating the change see the reverse as true. Examples of this reason are disagreeing that the benefits will come with new system; and systems cannot provide real experience for decision making. Low tolerance for change is also considered to be one of the reasons for user resistance. Low tolerance for change is the fear of not sufficiently developing the skills and behavior required. Some of the practical examples of this are fear of losing certain aspects of current situation; role conflict and ambiguity within the organization; relationship alteration and bringing higher skill levels to the job. Another significant reason for user resistance is increased efforts or additional efforts or abilities are needed for the job. It includes more effort in performing tasks in view of increased monitoring and need to spend more time for work.
Indeed, the user’s resistance to a proposed information system can be a real headache for the IS planner. Trying to make people like or at least agree to change from what they’re already used to can be a real challenge for the IS planners. I also agree that user resistance can be a source of frustration for IS planners because of the fact that it is the users who will generally use the information system being planned. If the end users will not use the information system being implemented, then it would really cause the company to waste a significant amount of resources. The first instinct that an IS planner is to try to make the users appreciate the information system by letting them know how the IS plan could significantly help them and the company in the long run. If they’re still unconvinced to use the system, then this is the time to put it to the top management’s hand and let them handle those users who oppose with your plan. Of course this would be different if the ones using AND opposing the information system plan is the top management itself. If that is the case, then this is the time for the IS planner to rethink of a better strategy to convince them or go to the last resort which is to change the whole IS plan according to the top management’s preference. This could be frustrating especially when the IS planner thinks that the IS plan that he formulated is for the company’s best interest but unfortunately, the top management thinks otherwise.
During one of our Software Engineering discussions, our professor told us that she experienced having problems with communicating with the other key personnel for the system development. She said that when you are developing a certain system, (especially when it is a big or mission critical system projects like train route system which involves a very big budget with higher risks) developers needs to have a meeting with all the key person for the project. Most of the time, these key person came from different fields of expertise. They could be different kinds of engineers like CE, ECE , SE, or even EE. They could also be physicist, chemist, accountants, business managers and a lot more. Because of different expertise, problems with communication arise. The electrical engineer will have a different language compared to IT professional therefore having the problem with understanding the requirements needed for developing the project. She mentioned that you generally common ground and meet half way to successfully develop a system.
From that SE discussion, I can say that miscommunication can also be a source of frustration when developing an IS plan. This kind of frustration usually happens when the type of language that the IS planner is using to relay about the IS plan does not make sense to the management or end users. This could be a problem when the management does not appreciate the level of technicality when dealing with the IS plan. This could be a source of frustration on the side of the IS planners because he should make the extra effort to make the non-technical people to understand the technical terms which is usually learned from years in college.
When I asked the MIS supervisor of Samulco if he ever experienced having problems concerning miscommunication with the other key person in the development of the system the he created, he answered that so far in his stay in Samulco he didn’t experienced these kind of problems but he did experience it while working with one of the big companies where he worked before. I asked him on how he solved that problem, he said that he didn’t. He added that generally (according to him) Filipinos don’t argue so much specially with IT people. He said that usually when an IT person said that ‘This is the best thing that we should do for the system’ the other person would usually agree with him.
In conclusion, developing an IS plan can be a critical job for most companies and can produce possible source of frustrations on the IS planner’s part. These frustrations can be different from IS planner to another but they all provide a venue for the IS planner to think of ways to mitigate them. It is important to take note of important source of frustrations from planning an information system and develop a plan first in order to avoid them or lessen their impact on the actual planning and implementation itself. I may not be an IS planner now but from what I learned from the interviews and researches that I conducted I can generally say that the key move here is to think ahead, consider even the smallest details and consider the end users of the information system a significant part of the plan itself.
References:
Shang,S. and Su,T.(2004).Managing User Resistance in Enterprise Systems Implementation.
Berthiaume, M. (March 13, 2009). Planning an IT budget: important considerations. New Hampshire Business Review. Date Retrieved: March 04, 2010.
Note:
Assignment 3
What are the two most frequently experienced causes of frustration of IS professionals and users while working on an IS plan? note: you are required to interview an IS professional/s for your answer ...(at least 3000 words)
Based on our previous discussions concerning the importance of Planning, I already learned that planning is a very crucial part of developing any kind of system. Planning is also an important part in the business process because it will describe the organization’s direction and the steps that the organization would take in order to get there. Just as what I discussed on my previous entries in my blog, an information system plan (ISP) is basically a plan concentrated on aligning the information systems of an organization to its business plan as a whole. An information system is comprised of the hardware, software and peopleware of an organization. Usually, the term information system is related to using technology as a crucial part of an organization. The term is also used to identify the computer-based system that an organization is using. In addition, an IS plan is just a part of the overall business plan of an organization. The IS plan of the organization must align with the business plan and must conform to the overall vision of an organization.
Since I’m still a student and my experience in developing an IS plan is still rudimentary, an expert opinion would help in the enlightenment of this topic. An information system professional is someone who is considered an expert and should have the experience in developing an information system plan for an organization that range from simple to complicated systems. Together with my classmates, we interviewed the MIS supervisor of Samulco for this assignment.
Based on the interview that we had with the MIS supervisor of Samulco, he identified the two most frequently experienced causes of frustration of IS professional like him and the end users while working on an IS plan.
In terms of Information System planning, there are some common problems that IS professionals encounter while working on an IS plan. Based on our interview with the MIS supervisor of Samulco last Monday (December 7) , he identified two of the most frequently experienced causes of frustrations of IS professionals like him. The first cause of frustration in IS planning that he mentioned is Budget Constraint. He said because of budget constraint, many problems arise from that problem alone. Because of budget constraint he said, there would be lack of manpower and lack of support. He cited a scenario where if the company wants a specific kind of system, but they don’t want to buy the necessary hardware for the job. This kind of problem would normally become a source of frustration of the Information System Planner. The IS planner should find a way to get what the client wants but in lesser price which in reality is a very frustrating thing to do. Another scenario that he cited is if you as a supervisor need at least three programmers but the company could only provide you with two because of budget constraint again, then that could also be a problem because it would be very hard to finish the necessary project in the allotted time if there is less manpower available for the job.
For most businesses, the requirements on the computing side at least should include:
* Hardware; the actual computers and servers.
* Software; programs and operating systems.
* Phone lines.
* Internet systems.
* Computing consumables and peripherals.
*Information Technology Support.
* Computer training, if needed, for staff.
The amount of technological requirements needed by a business will again depend on the size and type of business. This is by no means an extensive list and all companies will be different, but this does represent at least the basic technology requirements. The budget may increase or decrease depending on the sophistication of the equipment and the software needed.
Another issue that concerns budgetary factor is the decision whether to lease or buy technology. In the long run it may seem like buying is the less expensive option, but leasing is usually the cheaper option when repairs and upgrading technology are factored in. Most small businesses should take the leasing option in order to save on the capital outlay that comes with buying, and upgrading new technology.
Marc Berthiaume cited some important considerations that a company should put in mind when planning for an IT budget.
According to Berthiaume’s article, the following are some step-by-step guidelines to follow when planning your IT budget:
1. Calculate your technology costs from the previous year. Unless you are planning major changes in your IT strategy, this will give you a range to work with.
2. Most companies plan for moderate growth. These companies should set up a category for IT maintenance/support and one for new technology expenditures. (Companies should first calculate maintenance/support of existing equipment, since this number will remain approximately the same as the previous year.)
3. If you plan to purchase new systems or services, you should calculate the cost of the technology and then budget for installation and maintenance_ Depending on complexity, you also may want to budget for testing and downtime. Get estimates and make sure to pad this cost in case things take longer to install than originally expected.
4. Once you've calculated standard IT purchases and maintenance costs for the year, create a separate budget line for technology development--this is for longer-term IT planning, including new IT projects or major system upgrades.
5. Err on the conservative side and consider the possibility of leasing and outsourcing when faced with costly technology expenditures.
From those tips that I have cited from authors above, I can say that budgeting itself for an Information system (which already includes IT) is such a tedious task. Aside from the tips mentioned by article writers above, the IS planner could also develop his or her own standards on planning for the Information system based on the budget that he or she is given.
In my opinion, I do believe that budget constraint can be a real source of frustration from the IS planner’s part while working on an IS plan. The “budget” in a plan is the main means of resource to keep the system going. Without the necessary budget, it would be hard if not impossible to make the necessary activities/steps or improvements to implement the planning process as well as the implementation of the plan itself. If the necessary budget is not supplied, then it is expected that the project would require a longer time to be implemented or the output of the project itself would be not satisfying or worse would turn out to be a failure. As I mentioned above, one of the after effect of having a budget constraint is lack of manpower. From this problem alone, another problem can arise which is the extension of deadline. This problem usually arises because of the lack of manpower that would support the whole information system plan. The limited number of manpower will require a lot more time to finish a certain project compared to having more manpower to work on a certain project. If there is an extension of the deadline, another set of budget is now required to suffice the resources needed in finishing the project thus making the development of a project more costly than what was previously planned. This problem is one of the possibilities that an information system planner usually encounter that came from the budget constraint. The MIS supervisor also mentioned that budget constraint can also produce lack of support. The way I understand it, the lack of support that he means is the lack of support for the product by the top management because of the higher cost of purchasing the necessary requirements for an information system. This kind of problem could frustrate the IS planner because he or she will be restricted on the kind of information system that he wants to implement for the company.
Budget constraint is considered a frustration because of the fact that IS planners can’t do anything to make the budget bigger than what an organization can offer. It is a top management decision on how much is allocated on putting up an information system plan for their company. All the information system planner can do is make the most of what he is given and make the best plan out of the budget that was allocated for a project despite the constraint. Making a realistic technology budget will involve time and research. A long term technology budget is essential for the smooth running of any kind of business that gives importance and emphasis to technology.
The second cause of frustration among IS Planners would be the user’s resistance to a new system. He said that when you develop a system, then when it comes to the actual implementation, the end users tend to resist in using the system that you created. When we asked him, how do they solve or manage the user resistance of their system, he said that they don’t do anything at all. He said that you cannot really force someone to like your system. He said that if the user fervently denies using your system, then you could do nothing unless some big guy from the upper level would force them to use the system that you created. He also agreed when one of my co-interviewer told him (based from one of our discussions on Software Engineering), that user resistance is considered a failure of project. He added that you committed the mistake during the analysis phase when you didn’t anticipate what the end users’ reaction would be. This could happen if you didn’t planned/analyze thoroughly what the users really need and wanted the system to be. Obviously, when it comes to the user’s point of view, this could be also a source of frustration when the users are not inclined or comfortable on using the new system that the developers created.
According to the research paper made by Shari Shang and Tim Su entitled “Managing User Resistance in Enterprise Systems Implementation”, user resistance indicates a gap between change initiators and employees who try to maintain their status quo with undesirable behaviors toward change (Coch and French, 1948; Davison, 1994). Such undesirable behaviors of workers are a response to management-imposed changes in job and work methods (Piderit, 2000). Many researchers (Ginzberg, 1975; Jiang, 2000, Joshi, 1991; Keen, 1981; Kotter and Schlesinger, 1979; Markus, 1983) have identified reasons for user resistance. These reasons include loss of power, increased work, low tolerance, lack of trust and so forth. Similar circumstances can also be found with wide-scoped ES implementation. Many strategies have been suggested to manage user resistance; these strategies range from user participation, job redefinition, to some forceful actions. However, the most common mistake managers can make would be to follow only one approach or a limited set of strategies regardless of the situation.
Among the reasons for resistance that have been observed in various enterprise systems cases in the said study is the parochial self-interest which is the resistance to change to prevent losing something of value. Its contents include losing power and status; reduced scope for advancement or job security and loss of autonomy and control or specific skills. Another reason is misunderstanding and lack of trust or the misconceptions about the implications and insufficient information of the benefit and gains. Examples of this are misunderstanding the implementation of change and insufficient knowledge in using the new systems. Another reason for user resistance would be the different assessment where employees see more cost that benefits and those initiating the change see the reverse as true. Examples of this reason are disagreeing that the benefits will come with new system; and systems cannot provide real experience for decision making. Low tolerance for change is also considered to be one of the reasons for user resistance. Low tolerance for change is the fear of not sufficiently developing the skills and behavior required. Some of the practical examples of this are fear of losing certain aspects of current situation; role conflict and ambiguity within the organization; relationship alteration and bringing higher skill levels to the job. Another significant reason for user resistance is increased efforts or additional efforts or abilities are needed for the job. It includes more effort in performing tasks in view of increased monitoring and need to spend more time for work.
Indeed, the user’s resistance to a proposed information system can be a real headache for the IS planner. Trying to make people like or at least agree to change from what they’re already used to can be a real challenge for the IS planners. I also agree that user resistance can be a source of frustration for IS planners because of the fact that it is the users who will generally use the information system being planned. If the end users will not use the information system being implemented, then it would really cause the company to waste a significant amount of resources. The first instinct that an IS planner is to try to make the users appreciate the information system by letting them know how the IS plan could significantly help them and the company in the long run. If they’re still unconvinced to use the system, then this is the time to put it to the top management’s hand and let them handle those users who oppose with your plan. Of course this would be different if the ones using AND opposing the information system plan is the top management itself. If that is the case, then this is the time for the IS planner to rethink of a better strategy to convince them or go to the last resort which is to change the whole IS plan according to the top management’s preference. This could be frustrating especially when the IS planner thinks that the IS plan that he formulated is for the company’s best interest but unfortunately, the top management thinks otherwise.
During one of our Software Engineering discussions, our professor told us that she experienced having problems with communicating with the other key personnel for the system development. She said that when you are developing a certain system, (especially when it is a big or mission critical system projects like train route system which involves a very big budget with higher risks) developers needs to have a meeting with all the key person for the project. Most of the time, these key person came from different fields of expertise. They could be different kinds of engineers like CE, ECE , SE, or even EE. They could also be physicist, chemist, accountants, business managers and a lot more. Because of different expertise, problems with communication arise. The electrical engineer will have a different language compared to IT professional therefore having the problem with understanding the requirements needed for developing the project. She mentioned that you generally common ground and meet half way to successfully develop a system.
From that SE discussion, I can say that miscommunication can also be a source of frustration when developing an IS plan. This kind of frustration usually happens when the type of language that the IS planner is using to relay about the IS plan does not make sense to the management or end users. This could be a problem when the management does not appreciate the level of technicality when dealing with the IS plan. This could be a source of frustration on the side of the IS planners because he should make the extra effort to make the non-technical people to understand the technical terms which is usually learned from years in college.
When I asked the MIS supervisor of Samulco if he ever experienced having problems concerning miscommunication with the other key person in the development of the system the he created, he answered that so far in his stay in Samulco he didn’t experienced these kind of problems but he did experience it while working with one of the big companies where he worked before. I asked him on how he solved that problem, he said that he didn’t. He added that generally (according to him) Filipinos don’t argue so much specially with IT people. He said that usually when an IT person said that ‘This is the best thing that we should do for the system’ the other person would usually agree with him.
In conclusion, developing an IS plan can be a critical job for most companies and can produce possible source of frustrations on the IS planner’s part. These frustrations can be different from IS planner to another but they all provide a venue for the IS planner to think of ways to mitigate them. It is important to take note of important source of frustrations from planning an information system and develop a plan first in order to avoid them or lessen their impact on the actual planning and implementation itself. I may not be an IS planner now but from what I learned from the interviews and researches that I conducted I can generally say that the key move here is to think ahead, consider even the smallest details and consider the end users of the information system a significant part of the plan itself.
References:
Shang,S. and Su,T.(2004).Managing User Resistance in Enterprise Systems Implementation.
Berthiaume, M. (March 13, 2009). Planning an IT budget: important considerations. New Hampshire Business Review. Date Retrieved: March 04, 2010.
Note:
Assignment 3
What are the two most frequently experienced causes of frustration of IS professionals and users while working on an IS plan? note: you are required to interview an IS professional/s for your answer ...(at least 3000 words)
Comments