Risk Management in IT Projects – Case Study

Abstract

Purpose of the article: The first part of the article shows summarised information on risk management in projects based on the literature review. The second part of the article is a case study made on the basis of materials made available by the company implementing the AZTiE project. The case study shows how the risk management was carried out in the project. The techniques and methods of risk management used by the project manager were presented and risk groups were provided with assigned example risk factors, as well as the risk control plan envisaged for the specific factor. Methodology/methods: This article consists of two parts. The first part was developed on the basis of a literature study on project management and risk management in projects, in particular in IT projects. The second part was prepared on the basis of the consent of the AIUT Company and documents provided by the company. The documentation related to project management was analysed against this article. In particular, the basis for the study were documents such as progress reports, internal progress report, a static risk assessment card, Maximo training documentation, a risk management plan and identified risk factors along with control plans. Scientific aim: The aim is to present the course of the risk management process in a real IT project. Findings: The conclusion that can be drawn after the case study is that active and structured risk management in the project is one of the key success factors in the project. Conclusions: It is important that the entire risk management process is standardizsed and managed in an active manner. In the case study below, risk management was one of the success factors of the entire project.

Headnote

Abstract

Purpose of the article: The first part of the article shows summarised information on risk management in projects based on the literature review. The second part of the article is a case study made on the basis of materials made available by the company implementing the AZTiE project. The case study shows how the risk management was carried out in the project. The techniques and methods of risk management used by the project manager were presented and risk groups were provided with assigned example risk factors, as well as the risk control plan envisaged for the specific factor.

Methodology/methods: This article consists of two parts. The first part was developed on the basis of a literature study on project management and risk management in projects, in particular in IT projects. The second part was prepared on the basis of the consent of the AIUT Company and documents provided by the company. The documentation related to project management was analysed against this article. In particular, the basis for the study were documents such as progress reports, internal progress report, a static risk assessment card, Maximo training documentation, a risk management plan and identified risk factors along with control plans.

Scientific aim: The aim is to present the course of the risk management process in a real IT project.

Findings: The conclusion that can be drawn after the case study is that active and structured risk management in the project is one of the key success factors in the project.

Conclusions: It is important that the entire risk management process is standardizsed and managed in an active manner. In the case study below, risk management was one of the success factors of the entire project.

Keywords: project management, risk management, case study, IT project, risk factors, risk process

JEL Classification: M15, M19

Introduction

Nowadays, companies manage an increasing number of enterprises (Knosala, Łapuńka, 2015). This situation forces changes in the organisation from the process approach to the project approach (Trocki, 2014). Undertakings are no longer just typical activities that may be related to the construction of new infrastructure, e.g. ICT, or road infrastructure (Basu, 2014; Tabish, Jha, 2012). More and more projects are innovative in nature, which means that the product is a commercialised idea (Ahmad, Mallick, Schroeder, 2013). Projects whose final result are innovative products very often use IT tools aimed at supporting the project management process (Bulwan, Brittani, 2015). All projects participants are familiar with for example Microsoft products such as the OfficeSuite, communication platform SharePoint or MS Project, which significantly support and facilitate project management (Lightfoot, Beckett, 2010).

Also in the project entitled "Development and implementation of an innovative and proprietary system for managing teletechnical and energy infrastructure" (hereinafter only as the "AZTiE"), which will be presented in the case study below, the project team used IT tools that were designed to streamline the entire project management. It was not only decided to use the products of the Mountain View company, but also the Enterprise Asset Management (hereinafter only as the "EAM") software was used by the US giant of the IT sector. As the product of this project was an innovative and proprietary system for the management of teletechnical and energy infrastructure, the project team willingly used technical facilities supporting the whole process of not only planning but also implementing the project. One of the most important elements of any project management process is efficient risk management in the venture (Biskupek, Spalek, 2016). In the case study described below, the project team encountered a number of threats, risk factors and problems that had to be managed efficiently in order to be able to guarantee the success of the project for both AIUT and the client. Only the efficient management of the project by the manager and the appointment of a risk manager, whose sole task was risk management, saved the project from failure. The following case study presents a risk management process in the AZTiE project in a condensed manner.

1.Risk Management in IT projects

The IT project according to Frączkowski (2003) "is characterized by innovation, scope, risk, demand, human and material resources and the necessary time for implementation". Trzeciak (2015) believes that every project also an IT venture is burdened with risk. He defines risk as the "probability degree of occurrence of an activity or phenomenon that may have a negative or positive impact on the course of the entire project. One of the most important characteristics of the risk is not only the possibility of estimating its probability, but also estimating of its impact on the entire project. Thanks to this, the project manager can actively influence (manage) risk." Kutsch, Hall (2010) believe that risk is one of the most important processes in project management. Magdoń, Tchórzewski (2014) believe that there is no venture without risk. Zwikael, Ahn (2011) perceive the risk in the project as "a measure of the probability and effect of failure to achieve the project's goals. At the same time, in the literature of the subject, attention is drawn to the fact that the risk concerns not only the threat or loss, but also the chance to achieve better results in the project, or/ and at its individual stages." ICB (2009) defines risk management as "referring to the systematic use of principles, the approach and process of identifying risk assessment, and planning and implementing actions addressing risk. As a result, we get an environment in which proactive decisions are made." Chapman, Ward (2003) define risk management as a "management method that focuses on identifying and controlling areas or events that can lead to undesirable changes. It is an integral element of management based on a holistic approach to risk, i.e. risk is a collection of many different factors

Szczepaniak (2013) distinguishes four steps in the process of risk management in projects, which include: risk identification, risk analysis, risk steering and risk control. The figure below (Figure 1) shows the relationship between the above-mentioned steps in the risk management process.

Wysocki (2011) defines the risk identification as the first phase in the whole project risk management process. He believes that in this phase, the entire project team should undertake a joint discussion, the result of which should be an indication of the types of risk in the current undertaking. He recommends organising at least one meeting and preferably several, dedicated project risk issues. In this way, it is easy to make all members of the project team aware of the importance of the risk identification phase. Karbownik, Wodarski (2014) believe that identification of risk consists in determining potential threats (in other words risk factors). According to MoR (2007), the primary goal of this step is to detect threats that may limit or even rule out the possibility of achieving the goals and opportunities that may lead to improved results.

The next step in the risk management process is risk analysis, which according to PMI (2013) should be divided into two phases, qualitative risk analysis and quantitative risk analysis. According to PMI (2013), qualitative risk analysis is associated with the risk hierarchy, which precedes their further analysis or activities related to them and implemented by assessing and referencing their probability and consequences of occurrence. For the project manager, the key benefit of this phase is to reduce the level of uncertainty and focus on the most significant risks of a particular project. Quantitative risk analysis is associated with a numerical analysis of the impact of identified risks on the generally accepted goals of the undertaking. PMI (2013) believes that the key benefit of this process is the acquisition of quantitative information on risks that support decision-making, aimed at reducing the uncertainty of the entire undertaking. Another approach to risk analysis is presented by SPMP (2009), which treats this phase as one (without the division presented by PMI). It refers to two factors that determine the entire risk, namely the probability of occurrence and consequences of occurrence. Both PMI (2013), as well as Martin, Heaulme (1998) distinguish the four strategies of dealing with risk:

1. Accepting the risk and its potential effects in the form in which it occurs. This approach should be used for events with low impact.

2. Decreasing or completely eliminating the probability of events or their effects (or both). It becomes possible by changing one of the four key dimensions of the project: scope, budget, schedule or quality. This procedure works best with risk factors that are predictable.

3. Transfer of effects through insurance, guarantees or including subcontractors. In this way, you can deal with a risk which you can take out insurance. However, it is necessary to verify if the insurance is not more expensive than the effects of this risk.

4.Establishing a plan of future activities and provisions that will be used if an event that triggers a risk occurs. Such actions do not affect the probability, but they reduce the potential effects. Such a strategy can be applied to, for example, natural disasters and other unpredictable events in the future.

Burk (1999) also gives four strategies for dealing with risk, although he calls them a bit differently: eliminating risk, mitigating hazards, transferring threats, and accepting threats.

The third step in the project risk management process is planning risk response methods (risk steering). According to Pritchard (2001), this is the phase associated with the definition of actions by means of which problems are to be solved, which are related to particular types of risks that have been identified and analysed in previous phases.

The last phase in the above-described process is related to risk control. This phase consists in the ongoing monitoring of hazards during the implementation of the project and responding as planned with the emergence of threats. During this process, it is necessary to keep in mind the following principles (Förster, 2008):

1. The risk is variable - the likelihood of occurrence of threats and their consequences may change with time.

2. Many tactics can be used to efficiently manage risk.

3. One should not give up risk management in favour of general uncertainty and unforeseen events.

The risk is dynamic, as Pawlak (2006) claims. It should be borne in mind that the risk (level of risk) will change during the implementation of the project.

2.Risk management in the implementation project dedicated to the management of teletechnical and energy infrastructure of the application

In the implementation project dedicated to the management of teletechnical and ener- gy infrastructure of applications, AIUT as a general contractor faced many challenges in terms of project risk management. Due to this, it was necessary to manage the risk not only of the members of the AIUT project team, who in addition were dispersed in three locations, but also three teams of subcontractors. In the planning phase, the project manager, together with the project team, developed a risk management plan, while appointing a person to serve as the project risk manager. Risk management tools have also been defined. The risk management plan, which conceptually defined the risk management in the project, was updated for each of the project phases and, if necessary, adapted to the needs and requirements of the specific phase. The risk management plan also predicted that periodic meetings of the project team dedicated to risk management would be held periodically at the beginning of each week. The meetings were conducted in such a way that risks were identified under the chairmanship of the risk manager and were later subject to qualitative and quantitative assessment. In the next steps, the person responsible for the risk was assigned and a control plan was prepared (risk prevention). The last point was the verification and control of previously identified risk factors, due to the fact that some factors were only valid for a given project phase, or their impact on the project as a result of the ongoing implementation could change. For the AZTiE project, the leading tool for risk management was a static risk assessment card (SRAC). In order to use this tool, the risk manager defined 6 risk groups to which individual risk factors defined as a result of project progress were assigned. The likelihood of occurrence and its effect were assigned to the risk factors identified in this way. Both the probability of occurrence and the effect were determined on a ten-degree scale (1 smallest, 10 largest). Additionally, it was determined that the probability and effect determined on the scale 1-3 will be treated as little marked with green and the letter "M", 4-7 as medium and marked with orange and the letter "S", 8-10 as large and colour-coded red and the letter "D". The risk column will be the product of the probability and the effect of a particular risk factor and will be assessed on a scale of 1-100, where the 1-30 range will mean a low risk, which is marked in green and the letter "M", range 31-80 will be marked as medium risk, which was marked in orange and the letter "S" and the range from 81-100 was defined as a high risk, which was marked in red and the letter "D". After defining the risk control plan, the next column reassessed the risk after applying the risk control plan, which was also assessed on a scale of 1-100, where the range 1-30 meant low risk and was marked in green and the letter "M", interval 31-80 meant the average risk and was marked in orange and the letter "S", while the range from 81-100 meant a high risk and was marked in red and the letter "D". The table below presents a graphic presentation of the static risk assessment card in the AZTiE project (Figure 2).

The project team in the implemented project did not rely solely on one tool in the area of project risk management. The result of the arrangements between AIUT as a contractor and the client was also the necessity of periodically reporting the progress of design works according to the client's model. His report was in a descriptive form; it was submitted in an editable form and in a form that did not allow editing. This document consisted of the elements such as: 1. Confirmation of the tasks to be performed; 2. Comments on tasks that had to be performed and which are already delayed; 3. Information on problems encountered (critical problems) and their impact on the project; 4. Information on the application for changing the scope, their business value and impact on the project; 5. Information on newly identified risks; 6. Observation useful for Project Manager (PM); and 7. Annexes presenting the details. This document was sent as agreed by the 10th day of each month for the previous month. The following figure shows a graphical presentation of the progress report (Figure 3).

Reporting was not only limited to reports prepared periodically and transmitted to the client, also a system of internal reports was very developed. Each member of the project team weekly filled in the report progress of the work entrusted to them, report in the form of MS Excel was placed on the MS SharePoint platform, to which everyone had free access. For the project manager, such a solution was so simple that one member of the project team had a report at one location. Time-consuming merging of reports sent by each team member individually was excluded. The report showed in a simple way what tasks an individual team member performed during the week ended, what is the state of progress of these works, the expected end and information whether support is needed for the implementation (timely completion) of the task. The employee also had the opportunity to enter noticed risk factors related to the implementation of a given task. The following figure shows an internal report placed on the AIUT SharePoint site (Figure 4).

AIUT also used the system offered by the American IT industry tycoon to manage work in order to better control the implementation of the schedule. This application is part of the Enterprise Asset Management System (hereinafter only as the "EAM"). This system enables creation of work orders, so-called Service Requests (SR), which enable management of a specific task performed by a member of the project team. SRs were a mapping of tasks defined in the project schedule. The SR was assigned to an individual member of the project team; the supervisor was defined whose task was to take back the completed task. In the work order, dependencies were also established, among other things, which was to reflect the structure of the project's schedule. SRs had its designated beginning and end, as well as duration. A member of the project team, through the inclusion of a timer, and after the completion of work, turning off the time counter, recorded the actual time spent on the task. This made it possible to optimise the task execution time, and thus to exclude the risk associated with delays in the project. In the SR, there was also a record of all communication carried out on the subject of the task. It made it possible to follow the exchange of opinions and thoughts on the subject of the sentence implementation by individual team members - communication thanks to this solution was recorded in one place and always available to interested parties. The record in the SR was made by sending an email from the MS Outlook application and entering the subject in addition to the normal predicted content of the following combination #SRnumber#. The EAM system also enabled generating a report in the PDF file form, which presented delayed tasks, percentage of task execution and the level of implementation of the schedule. The following figure shows an example of the SR in the AZTiE project (Figure 5).

One of the basic risk management tools that were also used in the implementation of the AZTiE project is the project schedule. The project schedule was developed starting from the decomposition of the project scope defining the main tasks to be performed in the project. As a result, the Work Breakdown Structure (WBS) was created, which was the basis for creating the schedule. The division of the work structure was developed using the advantages of agile management, namely APF, which made it possible to create a master outline of the entire project schedule. Subsequently, the schedule was detailed for the next project phases or according to the needs for the next calendar period (e.g. month). In the next step, the duration, dependencies and connections with other tasks were assigned to the defined tasks. Subsequently, the project team attributed resources to tasks in the form of people who have to implement them, subject to assigning people according to their competence and skills, and taking care not to overload the particular person assigning them too many tasks to be implemented. The schedule prepared in this way was approved as a baseline. With MS Project, you could easily verify all deviations from the baseline. The application also enabled using the critical path to track whether the delay in a specific task has an impact on the delay of the entire project or whether it is a delay that will have no effect on the timeliness of the entire undertaking. In MS Project, a column named SR was added, in which job numbers from the EAM application were entered. Owing to this solution, a combination of two tools and better control of task management in the enterprise took place. Each task was described in detail in the EAM application. The risk management in the AZTiE project also took into account the simplest techniques that are used in any project, not always in a conscious manner. This means, of course, the regular meetings of the project team, in which the current topics of the project are raised, problems and ways to solve them are reported. These meetings during the implementation of the AZTiE were periodical, taking place every Monday. Their goal was to briefly summarise the week ended, discuss the work for the next week, report possible or anticipated problems and risks, how to mitigate or eliminate risk factors, how to resolve them, or how to avoid them. Although this technique is characterised by considerable simplicity, it worked very well during the entire AZTiE project.

3.Risk factors in the AZTiE project

Risk factors in the AZTiE project were divided into six groups: organisational, technical, technological, external, internal and formal-legal. Already at the stage of planning the entire project, the project team under the supervision of the risk manager identified risk factors that were related to the tender stage, which was long-term and included several negotiation stages. These factors have not yet been assigned to a specific risk group, because they were not yet associated with the implementation of the entire project. The entire difficulty for the project team together with the project manager and the risk manager consisted in the fact that each of the identified risk factors had to be analysed and estimated, taking into account its possible impact on the undertaking. Once the risk factor materialised, the project team had to be able to manage it in such a way as to mini- mise or exclude its native impact on the project. The following table (Table 1) presents the examples of risk factors from the technological group (only selected elements are presented due to the volume of the project and company and project confidentiality).

The next group to which the identified risk factors in the AZTiE project were assigned was the organisational group. The table (Table 2) presents several of the identified factors in the project belonging to this group.

The third group defined by the project team implementing the AZTiE project was a group related to internal risk factors. The following tables (Table 3) present an extract of risk factors assigned to internal factors.

The fourth group of risk factors defined by the team implementing the AZTiE project was a group of risk factors related to external factors. The table below (Table 4) provides a brief overview of the risk factors qualified by the project team and the risk manager.

The penultimate group of risk factors to which risk factors were assigned was a group of formal and legal risk factors. The table below (Table 5) presents an excerpt from factors assigned to this group by the project team together with the risk manager.

The last group of risk factors defined by the project team together with the project manager in the AZTiE project is a technical group. The table below (Table 6) presents examples of factors identified in the AZTiE project and assigned to the group of technical factors.

4.Conclusions

Risk management is one of the most important processes related to project management (Wachala, 2007), which is why this article consists of two parts. The first one presents the theoretical approach to management and was developed on the basis of a literature study in the field of project management and risk management in projects, in particular IT projects. The second part of the article is a case study of a project carried out at AIUT. In order to present the project implementation process, an analysis of the available documents related to project management was carried out and numerous interviews were conducted with project team members and project manager as well as risk manager. The above described case study of the AZTiE system implementation project was fraught with huge risks that the project team, the risk manager and the project manager had to deal with. In projects that show a high degree of innovation, such as the AZTiE venture, do not underestimate the risk in any way, but manage it in an active way. AIUT approached the concept of risk in a very professional way by appointing a risk manager whose task was risk management and close cooperation with the project manager in this topic. When analysing the case study described above, it should be noted that the approach to risk management in this undertaking was very methodical, owing to which it turned out to be one of the pillars of the success of this undertaking. Also, it should be noted that there is no one universal method developed in advance that is ideal for any project. In order to guarantee the success of the project, you should use a number of methods and sometimes even create your own. This approach was used by the project manager and the risk manager.

After analysing the entire risk management process in an enterprise, the following conclusions can be made:

1. The project was planned using the APF methodology and using MS Project and EAM applications as tools.

2. The risk manager was appointed for the efficient risk management of the project.

3. Innovative projects in which the original system is developed are subject to great risk.

4. The concept of risk is one of the key elements of the project's success.

5. The approach to risk management was methodical and planned.

6. Risks should be managed actively. You should not ignore risk management.

7. The project manager together with the project team developed six groups of risks, to which the identified risk factors were assigned.

8. The risk manager's way of managing the risk was based on commonly known and accepted methodologies and tools.

9. The risk factors have been systematically and periodically identified and evaluated from the beginning to the very end.

10. Risk management was carried out efficiently owing to the person of the risk manager.

11. Risk management turned out to be one of the pillars of the success of the entire undertaking.

In the above-described project, these methodologies and risk management tools have been applied. It should be remembered, however, that each project is unique due to its definition, which means that in other projects, which are designed to provide an innovative and proprietary IT system, the above-mentioned elements do not necessarily have to be successful. However, other techniques and methods of risk management may be used to guarantee the success of the different undertaking.

Sidebar

Received: 15. 7. 2018

Reviewed: 12. 11. 2018

Accepted: 27. 12. 2018

Artur Biskupek, Mgr lic.

Silesian University of Technology

Faculty of Organization and Management

Department ofAdministration and

Management

ul. Roosevelta 26, 41-823 Zabrze

Poland

Phone: [phone]

E-mail: [email protected]

References

References

Ahmad, S., Mallick, D. N., Schroeder, R. G. (2013). New Product Development: Impact of Project Characteristics and Development Practices on Performance. Journal of Product Innovation Management, 30(2), pp. 331-348.

Basu, R. (2014). Managing quality in projects: An empirical study. International Journal of Project Management, 32(1), pp. 178-187.

Biskupek, A., Spalek, S. (2016). Risk management in IT infrastructure projects on the example of the Lower Silesian skeleton network. XIX Innovation in the Management and Production Engineering Conference, Zakopane, pp. 13-24.

Bulwan, J., Brittani, A. (2015). Komputerowe wspomaganie zarządzania projektami [Computer aided project management]. High-speed Crawler Vehicles, 38(3), pp. 35-40.

Burk, R. (1999). Project management. Planning and Control Techniques. John Wiley & Sons LTD, Chichester, New York, 374 pp.

Chapman, C., Ward, S. (2003). Transforming project risk management into project uncertainty management. International Journal of Project Management, 21, pp. 97-105.

Förster, C. (2008). Risikomanagement in WebProjekten [Risk management in Web-Projekts]. Technical University of Munich, Munich, 278 pp.

Frączkowski, K. (2003). Zarządzanie projektem informatycznym [IT project management]. Oficyna, Wrocław, 163 pp.

ICB Competence Baseline (2009). IPMA. Retrieved from: https://www. ipma.world/individuals/ standard/.

Karbownik, A., Wodarski, K. (2014). Zarządzanie ryzykiem projektu w uczelni [Project risk management at the university]. Scientific Journal of the Silesian University of Technology, 70, pp. 189-202.

Knosala, R., Łapuńka, I. (2015). Operacyjne zarządzanie projektami [Operational project management]. Polskie Wydawnictwo Ekonomiczne, 246 pp.

Kutsch, E., Hall, M. (2010). Deliberate ignorance in project risk management. International Journal of Project Management, 28(3), pp. 245-255.

Lightfoot, J., Beckett, C. (2010). Microsoft SharePoint 2010 PL, Practical approach. Helion, 242 pp.

Magdoń, M., Tchórzewski, S. (2014/ Jakościowa analiza ryzyka w projektach sektora prywatnego [Qualitative risk analysis in private sector projects]. Scientific Journal of the Silesian University of Technology, 70, pp. 261-272.

Management of Risk (2007). Guidance for Practitioners. Office of Government Commerce, Crown, 184 pp.

Martin, J. E., Heaulme, P. F. (1998). Risk Management: Techniques for Managing Project Risk. Field Guide to Project Management, pp. 162182.

Pawlak, M. (2006). Zarządzanie projektami [Project Management]. Wydawnictwo Nauowe PWN, Warsaw, 276 pp.

PMI (2013). A Guide to the Project Management Body of Knowledge, 5th ed. Project Management Institute, 541 pp.

Pritchard, C. L. (2001). Risk Management, Concepts and Guidance, ESI International, 346 pp.

SPMP (2009). Zarządzanie projektami podręcznik [Project management manual]. Project Management Association Poland, Cracow, 330 pp.

Szczepaniak, W. (2013). Zarządzanie ryzykiem w projekcie współfinansowanym z Unii Europejskiej w szkole wyższej [Risk management in a project cofinanced from the European Union in a university, Finance, Financial Markets, Insurance]. Scientific Publishing House of the University of Szczecin, Szczecin, pp. 515-524.

Tabish, S. Z. S., Jha, K. N. (2012). Success Traits for a Construction Project. Journal of Construction Engineering and Management-Asce, 138(10), pp. 1131-1138.

Trocki, M. (2014). Organizacja projektowa [Project organisation]. Polskie Wydawnictwo Ekonomiczne, 147 pp.

Trzeciak, M. (2015). Znaczenie interesariuszy w zarządzaniu ryzykiem w fazie planowania projektu [The importance of stakeholders in risk management in the project planning phase]. Scientific Journal of the Silesian University of Technology, 86, pp. 399410.

Wachala, M. (2007). Metodyczne aspekty zarządzania ryzykiem projektu [Methodical aspects of project risk management]. Scientific Journal of the Cracow University of Economics, 753, pp. 253265.

Wysocki, R. K. (2011). Effective Project Management: Traditional, Agile, Extreme. John Wiley & Sons, 532 pp.

Zwikael, O., Ahn, M. (2011). The Effectiveness of Risk Management: An Analysis of Project Risk Planning Across Industries and Countries. Risk Analysis, 31(1), pp. 25-37.