Project Risk Management In Information Systems Essay Samples

Background

Information Systems, or IS, exist throughout daily life and have become a major aspect of the majority of businesses. It encompasses many areas, including hardware, software, infrastructure, and individuals who receive specialized training to plan, control, coordinate, and make decisions to help achieve the objectives of an organization (BusinessDictionary, n.d.). IS comprises many roles, including Transaction Processing Systems (TPS), Customer Relationship Management Systems (CRM), Business Intelligence Systems, and Knowledge Management Systems (Davoren). An important role within IS is that of a Systems Analyst. An individual in this position receives specialized training in order to assess an organization’s procedures and current hardware, software, and infrastructure to design system upgrades to provide an impetus to effective and efficient operations optimization (Bureau of Labor Statistics, n.d.). A Systems Analyst must possess an advanced knowledge computers to effectively analyze the current equipment as well as recommend system changes and have exemplary people skills to effectively convey ideas and concepts concerning these changes in order to excel as an “agent of change” (w3computing, n.d.). Systems analysis provides the methods to determine the needs of the person initiating change within an organization. This may originate from the Chief Executive Officer (CEO) or the manager of a department. Change is initiated for various reasons, such as upgrading or replacing existing computer systems or determining the need for an upgraded web site. The system analyst must work closely with the person requesting the change to ensure those needs are met while also working with the end users to ensure the changes will have the desired impact on the organization. Input from the end user is very important as they are the primary users of any computer system (w3computing, n.d.).
As the systems analyst is the agent of change, the focus is primarily on a problem and how to correct it. The systems analyst uses paracomputing to create a larger view of the issue by attempting to consider factors that are not considered to be a part of the problem, but can experience the effects of any changes made to correct the problem. In addition to an agent of change, the systems analyst must be a motivator, an organizer, an architect, and an intelligent salesperson. The systems analyst must be able to convince end users that they not only need these changes, but they want these changes (Researchgate, n.d.).
The systems analyst works in conjunction with the IS/IT manager. The duties of the manager includes evaluating the data obtained by the systems analyst to determine feasibility of proposed projects and presents the findings to upper management. The manager may also serve as project manager. The manager is also responsible for all activities within the IS/IT department and serves as the liaison among other departments as well as upper management. The manager normally reports to the Chief Information Officer or CIO (O*NET Code Connector, n.d.).
Change is inevitable. In IS, change is a constant as new technology is released on an almost-daily basis. While some companies may demonstrate a resistance to change, others may undertake the necessary efforts to remain current. This presents the need for various projects. A common project consists of systems design. This process requires a systematic approach to each aspect that is required, including establishing the initial requirements that set the basis for the project. Systems design includes a thorough system analysis, engineering, and architecture to determine hardware and software requirements, and the data to be processed as well as how it proceeds through the system (Techopedia, n.d.). Risks are everywhere as the probability of risks exists throughout each phase of design, which necessitates the need for a cohesive project risk management plan. What can go wrong, will go wrong. This is so true within Information Systems. By spending the necessary time to research and develop a cohesive plan, certain risks can be minimized; however, this is not foolproof. There will be other issues that the best of plans will be unable to account for in advance and these must be rectified on an as-needed basis.

Literature Review

Information Systems projects follow a System Development Life Cycle, or SDLC, which consists of six consecutive steps, which are detailed below:
A preliminary investigation is performed to determine if designing a new system is necessary or if modifying the existing system is a possibility. This step provides a feasibility study to identify the primary issues and helps determine what, if any, proposed changes will be compatible and fiscally sound.
A complete systems analysis is performed by collecting and analyzing data to probe deeper into the issues to determine how to proceed to correct these issues as well as determine the needs of the end users. This provides clarity on both the issues at hand and the desired results.
The system design phase is next. During this phase, a blueprint is created to detail exactly what needs to be done as well as the steps taken to achieve the ultimate goal. It enables the creation of necessary tools, such as a data dictionary, to define the characteristics of all data to be utilized within the system. This design phase allows the opportunity to determine how data will be entered, accessed, and output, including report design. It details security requirements and methods to prevent data loss. A cost benefit analysis is performed at this point to determine if the proposed system will justify the associated costs.
The next phase is system acquisition. This is the phase where the determination of building new systems or buying off-the-shelf systems will be made. At times, off-the-shelf may be the more cost efficient method, but can vary depending on the amount of customization is required. Any customizations will require additional costs.
During the implementation phase, data is transferred from the old system to the new system. This is accomplished through one of four ways: direct conversion in which the old system is shut down and the new system is immediately put into use, parallel conversion in which both systems are used in conjunction with one another as the new system is learned and initial issues are resolved while the old system is phased out, pilot conversion in which one new system is installed to determine if the expected results are achieved, with the remaining systems implemented upon approval, and phased conversion in which the new system is integrated by module through direct or parallel conversion. Direct conversion is the quickest method.
System maintenance remains in place throughout the life span of the system. This consists of software and/or hardware upgrades and updates. This continues until the systems undergo another upgrade. It is a never-ending process.
Once the systems are fully in place, a post implementation review is performed as an evaluation technique to ensure that everything is performing at or above expectations. This allows the opportunity to correct any issues that may have occurred throughout the process and provides the final determination concerning the overall success of the project (Al-Qawasmi, 2015).
Durkovic and Rakovic present the three levels of determining the success of an IS project. These are successful, in which projects complete on time and within the budgetary constraints, “challenged projects”, in which the projects are successfully completed, but faced issues adhering to the budgetary and time constraints, and unsuccessful, in which the project remained incomplete. The majority of IS projects are considered to be challenged. It is indicative that smaller projects completed within a shorter period of time are considered to be more successful (2008, p. 13-19).
When based on financial impact, risks may be classified as critical, major, or regular. A critical risk has the potential to present dire consequences, such as bankruptcy. A major risk is one in which the corporation remains solvent, but will have to undertake certain measures, such as selling property, to continue to operate. Regular risks do not cause any financial distress and business proceeds as normal (Smejkal & Fortinova, 2012, p. 41).
Risks are present in every level and every phase of any project. This includes system level, system of systems, and enterprise engineering programs. For effective risk management plans, senior leadership and stakeholders must support the effort through commitment and participation. Risk management has to become a part of the project’s procedures and included in the systems engineering plans (Systems Engineering Guide, n.d.).
Risks may present themselves as threats or vulnerabilities. Threats may be intentional or accidental. Potential threats include accidental disclosure, acts of nature, unauthorized software modifications, such as viruses, unauthorized bandwidth usage, electrical disturbances, telecommunication disruptions, and errors within system configurations. Vulnerabilities include lacking or having a poorly designed contingency plan, a lack of contingency training for the staff, a lack of system recovery plans, failure to perform backups of data and operating systems, and not providing offsite storage for backups (Elky, 2006, p. 2-3). An effective risk management plan provides options and solutions for these situations.
Jutte (n.d.) provides ten primary steps for developing any risk management plan. These are as follows:
Include risk management in the initial planning for the project. Do not wait for risks to become apparent. Be prepared for risks before anything happens in order to take care of any issues as they arise instead of allowing risks to take control of the project.
Identify possible known risks to plan effectively on resolving these as they arise. Also take into consideration that it is impossible to identify all potential risks. The members of the project team may prove helpful based on individual experiences or be able to provide possible insight to possible risks during team meetings. Another possibility of identifying potential risks is to search the Internet for specific case studies to provide possible insight into the project at hand.
Communication is essential. Discuss possible risks during team meetings and let team members know that risk management is a priority and not an afterthought. Ensure that upper management or the client is aware that risks may occur. Notify upper management or the client of larger risks that are encountered. While the project manager can make suggestions on how to proceed, decisions concerning these risks must be made by the person who is ultimately in charge.
Identify if a risk is a threat or an opportunity. Not all risks are negative and some can have a positive impact on the project as well as the organization.
Establish risk ownership. While identifying potential risks are important, that is just the first step in the process. Assign risk resolution to team members. This conveys a sense of responsibility and encourages team members to be proactive in ensuring these risks to not evolve into problems.
Assign risks based on priority. Not all risks are equal. Prioritize risks according to the potential impact based on a pre-established set of criteria.
Perform an analysis of risks. Understand the individual risk that is being faced in order to effectively remove or reduce that particular risk.
Plan the implementation for risk responses. Identifying possible risks in advance is not enough. It is imperative to have plans in place concerning how to effectively avoid, minimize, or accept the risk, based on predetermined criteria.
Document any and all project risks. Documentation can also provide detailed notes concerning meetings that have been conducted throughout the processes of project planning and risk management. This can prove invaluable in issues where clarity is needed.
Track risks and associated tasks daily. Keep records concerning the potential risks, risks responses, progress reports, and impact of each risk on the project. Use documentation to benefit the project team and possibly, provide insight into future projects.
Even projects with the most astute plans in place run the risk of failing. These reasons can be caused by a variety of issues, such as the base requirements change during any of the phases of the SDLC, the project exceeds the budget, or the time constraints are not met. According to a survey conducted by the Macrothink Institute, common issues facing IS projects are detailed below:
Customization is requested as the project progresses. These customizations are not initially identified at the onset of the project and are completely dependent on the customer and their specific needs. While some changes are easy to integrate into the system design, others are not.
Design specifications are altered later in the project. The requirements should be communicated and noted at the beginning of the project. These requirements should be agreed upon by both the IS professional and the client. When these requirements change later, it is often cost-prohibitive to scrap the original plan and start over.
The projected timeline is underestimated. It is easy to miscalculate the amount of time necessary to complete an IS project. Underestimating the time required to complete the project causes the project team to become stressed while trying to rush to complete the project within the specified timeframe. This can also cause errors to happen as the project team can make careless mistakes in this rush to beat the clock.
Internal communication is insufficient. Effective communication is essential to almost everything throughout life. IS is not an exception. When communication degrades, the result is arguments and infighting. This deteriorates the cohesiveness of the team and the project suffers.
End users were not involved during the initiation of the project. This often leads to resentment, especially in larger projects, as the end users may often feel as if their individual roles are diminished and their needs are not considered.
Available resources are insufficient. Resources include people, hardware, software, equipment, and specialized skill sets, among others. When resources are underestimated, or if key people are unable to participate throughout the project, it creates a strain on the remaining resources.
The requirements and scope are poorly defined. A clear definition of the requirements and scope of any project are of utmost importance. Without this clarified, the necessary resources cannot be allocated. It also provides a manner of allowing complex changes that were not considered during the design process to kind of sneak in and risk creating conflicts in the project.
The specifications were incomplete when the project began. Incomplete specifications do not allow a clear picture of the end results to be visualized. To add to the confusion, when the specifications are not clear, they can change as the project progresses.
Key individuals, such as the project manager, business sponsor, or vendor manager, change. When key individuals change, the project changes as a result. A different project manager is going to have a different style of managing the project, resources may be allocated differently, and the priorities of the project may change. When key individuals change, however, it does not mean the project is automatically destined to fail.
IS projects do fail. At times, there are no ways to prevent this from occurring. Failure is defined by the level of severity. Critical factors are determined if the failure is caused by any of the following: if the system as a whole performs at a sub-par level or does not operate as expected, if it is not user-friendly or fails to perform as intended, if the cost is excessive and the benefit gained is outweighed by the costs to obtain, or the system contains complexity issues and development is scrapped. Termination failure is caused of the development or operation is terminated. If support for the project continues, it is not considered to be a failure even if it is sidetracked for any period of time (Yeo, 2002, p. 243).
Shacklett offers ten suggestions about what to do when there are no other options (2014).
Establish good communications at the beginning of a project. This provides a level of comfort for the stakeholders that if a project is failing, the stakeholders know that it will be handled professionally and in an unbiased manner.
Accept responsibility by not making excuses. There are many reasons why projects fail, but do not try to blame others when it is your responsibility.
Watch for warning signs in advance. A project normally does not just fail without advance notice. Warning signs are normally existent especially when an efficient project manager is on the watch for signs of danger, regardless of how subtle these signs may be.

Have the ability to end the project when significant signs that the project will fail are present.

Review the failed project to determine exactly why the project failed. Have the project team pull together to allow an open discussion concerning the challenges that could not be overcome.
Find the good in any failed project and turn it into an advantage. The good tidbits can be viewed as valuable even within a failed project.
Critically assess yourself and the project team. Determine how the individual performances affected the overall project. This also extends to the stakeholders and the vendors. Leave no one out of this critical review. While it will not save this project, it could prove beneficial later.
Establish checkpoints in advance in order to know when to leave the project. These checkpoints should be identified before the project begins and the team members and stakeholders should be aware of these in advance.
Create a Plan B. Have alternative plans established. No plan is perfect and issues will arise. Prepare and use the Risk Management Plan to ensure that options are available.
Divide the project into smaller, more manageable segments. This provides an opportunity to ensure a project stays on time and on budget.
An estimated 50 to 80 percent of all large-scale projects fail. To combat this, Dorsey reinforces that the support of upper management is a necessity and that a sound methodology is essential to the success of any project, while issuing a third directive: provide a higher standard of technical leadership by placing an individual in the role of project manager who has the experience of participating in a similar project that completed successfully. The key aspect in this position is “technical” as without that experience and expertise, failure is almost unavoidable (n.d.).
This particular case study, released by Yusuf, Gunasekaran, and Abthorpe in 2003, details the implementation of an Enterprise Resource Planning, or ERP, system into a major corporation who is recognized world-wide as being a premier manufacturer of luxury vehicles. This corporation, Rolls-Royce, returned to being a privately owned company in 1987 and in 1989, acquired Northern Engineering Industries, followed by the acquisition of the Allison Engine Company in 1995. These acquisitions expanded Rolls-Royce from luxury vehicles to interests within industrial power and aero propulsion. With facilities in 14 countries, the need for a new organizational structure was identified in March 1998. The decision was made to implement SAP, a leading ERP product. Prior to that, Rolls-Royce had implemented over 1,500 systems, with many being developed internally. This proved to be costly, difficult to maintain, and the data was inaccurate, inconsistent, or inaccessible. After twenty years of various programs, the decision was made to implement SAP.
A partnership with electronic data services (EDS) was forged in 1996. EDS assumed responsibility for developing Rolls-Royce’s Information Technology, or IT, systems through an outsourcing agreement in which the IT department for Rolls-Royce were outsourced to EDS. EDS became responsible for the existing structure and IT services, including providing technical support for the existing systems. EDS also provided specialists for the EDS project.
The SAP implementation faced some obstacles. A primary issue was cultural differences. EDS trained key personnel with Rolls-Royce to overcome this issue. A secondary issue was within the constraints of SAP as it requires a more rigid business structure. Employees with Rolls-Royce adjusted to this change as Rolls-Royce modified the way it does business. A third issue was retrieving the data from the legacy systems. EDS had programmers create code to facilitate this task. Some systems at Rolls-Royce, such as the CAD system, remained unchanged to avoid increasing the overhead. The network infrastructure was upgraded and additional computers were added at a cost of around two million pounds.
Phase I initiated a short, but intensive, study to set the scope while providing the outline plan and the total cost. An ERP Core Team formed to oversee the implementation process. Phase II provided a detailed plan and the prototype system was created and installed. The existing projects within Rolls-Royce were merged and training began. Reviews were conducted to ensure that everything was progressing according to plan. The implementation in Phase III was separated into two ‘waves’ as concern about changing the operations practices was addressed. Wave 1 replaced the legacy systems while wave 2, which took about a year to complete, was not fully operational until wave 1 was completed. Certain issues were faced as testing progressed, such as user passwords were invalid and certain values were incorrect in between the legacy systems and SAP, but were overcome with corrections being enacted. The largest issue encountered was due to the vast amounts of data that had to be updated to be compatible with the new system and transferred.
Anticipated issues included a failure for Rolls-Royce and EDS to reach an amicable agreement concerning goals, not being able to acquire the necessary hardware and infrastructure prior to and during implementation, inability to provide adequate and ongoing support from EDS and Rolls-Royce, a resistance to change, the perception that this process was not a change in process methods and was simply an IT implementation, and the possibility that the data issues could not be resolved, among others.
As the final phase continues, Rolls-Royce has managed to make drastic changes to the way the corporation operates. The full extent of the project will remain unknown until the system has been in place and has experienced a period of stability for at least a full year; however, some benefits, such as lower IT cost and on-time delivery to customers, will be noticeable almost immediately. By working with EDS every step of the way and ensuring the lines of communication open, this process has been successful as of the date of the release of the case study; however, the results of a follow-up study have not been located at this time.

Conclusion

In a worse-case scenario, the project fails. Even though it is impossible to identify all potential risks in advance, it is important to be aware of the known possible issues in an attempt to prevent a minor issue becomes a major issue. If failure is imminent, the methods of mitigation detailed above should prove beneficial.
Change may inevitable, but it does not have to be feared and it does not have to be avoided. Positive change should be embraced as it provides the method to remain competitive in an ever-charging world.

Works Cited

Al-Qawasmi, O. “What is System Development Life Cycle?” Airbrake. 09 January 2015. Web. 05 April 2015. <https://airbrake.io/blog/insight/what-is-system-development-life-cycle>
Bureau of Labor Statistics. “Computer Systems Analysts”. n.d. Web. 05 April 2015. <http://www.bls.gov/ooh/computer-and-information-technology/computer-systems-analysts.htm>
BusinessDictionary.”information system”. n.d. Web. 05 April 2015. <http://www.businessdictionary.com/definition/information-system.html>
Davoren, J. “Types of Information Systems in an Organization”. Chron. n.d. Web. 05 April 2015. <http://smallbusiness.chron.com/types-information-systems-organization-43097.html>
Dorsey, P. “Top 10 Reasons Why Systems Projects Fail”. Dulcian. n.d. Web. 06 April 2015. <http://www.dulcian.com/articles/dorsey_top10reasonssystemsprojectsfail.pdf>
Durkovic, O. & Rakovic, L. “Risks in Information Systems Development Projects”. Management information Systems, Vol. 4, No. 1, p. 13-19.
Elky, S. “An Introduction to Information System Risk Management”. SANS Institute InfoSec Reading Room, 31 May 2006, p. 2-3.
Jutte, B. “10 Golden Rules of Project Management”. Project Smart. n.d. Web. 05 April 2015. <http://www.projectsmart.co.uk/10-golden-rules-of-project-risk-management.php>
O*NET Code Connector. “Computer and Information Systems Managers”. n.d. Web. 05 April 2015. <https://www.onetcodeconnector.org/ccreport/11-3021.00>
Project Management. “Project Management – Techniques – Risk”. n.d. Web. 05 April 2015. <http://www.proj-management.com/Project-Techniques-Risk.html>
Researchgate. “The Systems Analyst”. n.d. Web. 05 April 2015. <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&cad=rja&uact=8&ved=0CFgQFjAJ&url=http%3A%2F%2Fwww.researchgate.net%2Fprofile%2FSadagopan_Parthasarathy%2Fpublication%2F268152535_Who_can_be_a_good_Systems_Analyst%2Flinks%2F5462fd3e0cf2c0c6aec1c186.pdf&ei=rxMiVZ6xKczusAWRpIOgDA&usg=AFQjCNGbOjcY8VzXNqTjsktN0eVrY_1vfw&sig2=s1G_uvdMbGjv0eWsGLOg6g&bvm=bv.89947451,d.b2w>
Shacklett, M. “10 ways to deal with a project gone wrong”. TechRepublic. 05August 2014. Web. 05 April 2015. <http://www.techrepublic.com/blog/10-things/10-ways-to-deal-with-a-project-gone-wrong/>
Smejkal, V. & Fortinova, J. “Risk Management in Information Systems”. Systemova Integrace, p. 41.
Sweis, R.J. “An Investigation of Failure In Information Systems Projects: The Case of Jordan”. Macrothink Institute, Journal of Management Research, Vol. 7, No. 1. 2015. p. 179-180 Techopedia. “System Design”. n.d. Web. 05 April 2015. <http://www.techopedia.com/definition/29998/system-design>
Systems Engineering Guide. “Risk Management Approach and Plan”. Mitre. n.d. Web. 06 April 2015. <http://www.mitre.org/publications/systems-engineering-guide/acquisition-systems-engineering/risk-management/risk-management-approach-and-plan>
Yeo, K.T. “Critical failure factors in information system projects”. International Journal of Project Management 20 2002, p. 243.
Yusuf, Y, Gunasekaran, A., & Abthorpe, M.S. “Enterprise information systems project implementation: A case study of ERP in Rolls-Royce. International Journal of Production Economics. 2003 Elsevier B.V.
W3computing. “Roles of the Systems Analyst”. n.d. Web. 05 April 2015. <http://www.w3computing.com/systemsanalysis/roles-systems-analyst/>
W3computing. “Need for Systems Analysis and Design”. n.d. Web. 05 April 2015. <http://www.w3computing.com/systemsanalysis/need-systems-analysis-design/>