Devising new Software Project Risk Management Model: MARUNA

Transcription

1 Devising new Software Project Risk Management Model: MARUNA Bekim Fetaji South East European University, Computer Sciences, Ilindenska bb, 00 Tetovo, Macedonia Abstract The focus of this research is the development of a practical risk management technique and its assessment. This study systematically tested the correlation between critical activities and critical paths and risk scenario case management applied in project planning since its early beginning up to end. Risk management is critical to success in complex projects but is seldom applied effectively and its integration within software life cycle is missing. Based on the literature review discovered a high rate of ICT projects failure. What were the causes of these expensive and seemingly uncontrollable failures of ICT projects? Despite the review of considerable published literature on the risk management for ICT software projects and their frequent failure did not discover a satisfactory Risk Management framework and model specific to ICT software projects. In order to investigate these issues a research study was realized and as contribution a MARUNA risk management model was created. Its main contribution is that it integrates all the project planning stages. The results of applying the MARUNA Risk Management Model have been tested and the findings and recommendations are derived from the extensive body of evidence collected, in both written and oral form. Keywords Risk management, risk scenarios, it project management, project failure, risk management model. Introduction Different studies consistently show the same thing that 0 0 percent of all ICT projects fail while a large percent of them can not finish because of the 90% syndrome missing functionalities and cannot pass the acceptance testing. [] suggested that 70% of ICT projects are doomed by practitioners inability to deliver projects on time, within budget, and with appropriate quality that work as required. A study by [] of 800 IT managers across eight countries shows that three problems with IT projects stand out from the rest and these are:. Overrun on time (%). Budget overrun (9%). Higher than expected maintenance costs (7%) According to [] a study on the state of IT project management in the UK carried out by Oxford University and Computer Weekly reported that a mere % of IT projects were considered successful. Striking a balance between the principles of IT with the planning, structure and accountability of managing a successful software project especially its return on investment ROI is difficult. Moreover, over half of all software systems projects overrun their budgets and schedules by up to 00 percent or more according to []. Of the projects that fail, approximately half of all those that are restarted fail again. Yet management tools and techniques, as well as software development techniques, are constantly improving. What are the causes of these expensive and seemingly uncontrollable failures of ICT projects? [] suggests that software project Risk Management is often overlooked in project management. Risk Management ensures that the project scope allows realistic schedules, cost and performance expectations.. Background Research The literature review provides an understanding of past research into Risk Management in the context of IT software projects. The published literature documents common strategies for assessing and managing risk. Many writers have proposed, tested, and evaluated methods for assessing and minimizing IT software project risk ([], [], [], []). [] analyzed why ICT software projects continue to fail, arguing that organizations need to improve Risk Management if they are to reduce high project failure rates. According to [] software project risk Management should be costed and included in the total cost of the project; organizations need to realize that Risk Management is intrinsic, is unavoidable, and will cost less if it is recognized has an essential part of project management. 0 TEM Journal Volume / Number / 0.

2 [] suggest that Risk Management is orientated towards identifying and controlling project variation and foreseeable uncertainty. [] identified the major causes of project risk as lack of planning and lack of top management control during the project life cycle. He proposed a Risk Management cycle, comprising four phases, each of which must be executed and, if necessary, repeated as required to minimize risk. The four phases were: ) Establish that a risk exists; Analyze the risk severity and probability; ) Plan to manage the risk using the risk s severity and probability of occurrence; and ) minimize risk consequence. These four phases are analogous to Edward Deming s quality cycle that comprises the four phases Plan, Do, Study, Act. [7] argued that many organization continue to fail when implementing IT projects such as Enterprise Resource Planning systems (ERP). He argues that the high cost of ERP system implementations and failure to adopt appropriate risk strategies endangers the entire organization. Most of the studies reviewed ( [][7]) argue the importance of incorporating Risk Assessment early in the process of software development as risk can affect the time and budget constraints. Despite the review of considerable published literature on the risk management for ICT software projects and their frequent failure did not discover a Risk Management framework and model specific to ICT software projects.. Devising the MARUNA Model MARUNA is an acronym that stands for: Managing and Assessing Risks Using Network Analyses Steps in Constructing the Network Analyses Diagram Do a work breakdown. Estimate the duration of activities. Establish logical sequence between activities (dependencies). Draw the basic network in rough. Calculate the total project time and floats. Identify activities on the critical path. 7 Allocate resources. 8 Smooth out the network. 9 Check the network. 0 Discuss and refine the plan until it is appropriate. Work breakdown, by carefully analysing all aspect of the project both the technical and nontechnical, a list can be made of the activities that need to be completed in order to achieve the project aims. This list is the basic data for drawing up the project network. Duration, the time required for the completion of the activity. This may be calculated knowing the resources available or may be calculated knowing how much time is available to complete the activity (the appropriate resources may be allocated later). See notes on activity timings at the end of this tutorial Dummy Activities, one of the fundamental differences between the activity on arrow and activity on node networks is that the latter does not make use of dummy activities. Dummies are added to a network in order to clarify dependencies where an ordinary arrow cannot reflect this correctly. Dummy activities have no duration. They may be used freely when first drawing the network. Unnecessary dummies should be eliminated later to simplify the diagram Events or nodes are points in time, do not have a duration but represent the start and finish of activities. They often coincide with a deliverable (some significant tangible products that has to be completed) or a milestone (a point in the project where an assessment of progress made) of some sort. They are a point in time and have no duration but they can be used to show the earliest time at which following events may start and the latest time at which preceding events may finish. Events which are the focal point of a large number of activities can be elongated as a vertical sausage to allow parallel activities to be drawn horizontally. Earliest Event Time, the earliest time by which this event can be reached and subsequent activities can begin. For the first event this is zero, for other events it is calculated by adding all the durations of events leading up to that event. It there are two or more paths into an event then the one with the longest duration becomes the earliest event time. Latest Start Time, the latest dates at which an event can occur if the end date is not to be affected. Working from right to left calculate and enter latest event times by subtracting duration times. Where there is more than one path the correct latest time will be the smallest of the alternatives. Critical Paths, this is a path through the project where a series of tasks have no slack or float in their TEM Journal Volume / Number / 0. 0

3 duration such that if one task on the path goes beyond its deadline then all the subsequent tasks slip and the project deadline is jeopardise. The critical path is the longest path from start to finish. For all activities on the critical path the Earliest Event time and the latest start time are the same. There may be more than one critical path in a system. Float, the float is the difference between the time available to complete the activities and the estimated duration (actual time required) for the activity. Sub networks, when the initial drawing is completed, significant activities on the network should be expanded into more detailed networks. For example the activity 0 Evaluate package in figure could be drawn as in figure NN. Sometimes a large project may involve many different departments, groups or other natural divisions. It may involve hundreds of interdependent tasks in which case the different interested groups may compile there own network diagram for their part of the system. Separate diagrams for parts of the project can then be brought together to see how they fit in with the Project Master Schedule. This combining of a bottom up and top down approach to scheduling the project is often a successful way of getting many people committed to the plans. Resource Requirements, in drawing the networks in figures and only the tasks to be done have been considered and not the resources needed. For instance it is assumed that someone is available to prepare the potatoes whilst someone else is available to make the kebabs. If this were not the case and the same resource (person) had to do all the tasks then the diagram and the Bar B Que would not be ready for four and a half hours. Also there is a new critical path through the project. Note that heat the charcoal has a duration of. hours. This is the elapsed time from lighting the charcoal until it becomes warm enough to cook the food. There is no labour involved; the activity itself takes two or three minutes. However there is a waiting period that is part of the logic of this network and effects other activities so it must show up on the network. Resource constraints, planning and scheduling has to be carried forward one step at a time and consideration of resources constraints is a step that is taken after the initial network is drawn. The first step is scheduling is to draw he network to establish the logic. The second step is to estimate the duration and calculate the overall project timetable. The third step is to examine the resources and smooth out the schedule. Inevitably this procedure is repeated several times before the optimum (or an acceptable solution is found) Drawing of the diagram, the number of people involved in drawing a network depends on the size and of the project and the degree of interaction between departments and activities. At the smallest end, individuals will draw networks simply to plan their activities. For larger complex planning, a representative from the different responsible groups may be involved. Those involved should have the authority to commit resources and agree the final plans. On large projects, actually drawing the network may be the job of an assistant who is skilled in that tasks and not necessarily part of the team making the decisions. The network is drawn quickly and roughly to start with and is gradually refined as the ramification of decisions become obvious. The network are drawn for all to see on paper, a blackboard on a white board.or whatever. After the meeting the diagram will be taken away and cleaned up for publication. It is highly likely that this job will be done now a week s using a Project Management Software Package of some description.. Calculating activity timings Calculating activity timings for each activity in the network is given a time. It is estimated as being the time required for the work to complete the task. In PERT (programme evaluation and review techniques), three such estimates are required for every activity these are:. Optimistic time (the best time possible for completing the activity). Pessimistic time (that is, worst possible time). The most likely time These three times are used to give a weighted mean form the formula: Time = Optimistic time + *MLT + Pessimistic time This calculation is repeated on all activities in the network and is used to predict the probability of completing the project by the required deadline. Some organizations recognize that technical staff are eternally optimistic and so the normal distribution curve is not really suitable for predicting the spread of estimating errors. Such organizations may decide to skew the distribution curve deliberately and use a variation on the formula such as below. Time = Optimistic time + *MLT + *Pessimistic time 0 TEM Journal Volume / Number / 0.

4 . Case Study In order to apply the MARUNA technique we have used the following case study project. A Software project involves developing a financial software system for a small cash and carry organization. The design is complete and there is a need for the following activities to take place. The work breakdown has been done and compiled is the following list. 0 0 ACTIVITY Requirem ents Analyses System Design Write data entry software Test Hardware DURATION DEPENDANCIES 9 0 0t Pt O T () 8 P T 8 ( ) ( ) ( Write Program Specs. Construct Programs Unit Testing Integration Testing Implementation Acceptanc e Testing 0 0, 70, ,80, 0 7 () () 7 () () Table. Work breakdown structure. Risk management analyses ( ( 0 Create Data files Detaile d Design Create Help docs Figure. Solution using Network analysis TEM Journal Volume / Number / 0. 0

5 In our project we have two main critical paths. The critical path is a path through the project where a series of tasks have no slack or float in their duration. Critical paths: Cp Cp Calculating the estimation MLT = weeks Td= Td= This project will approximately be finished in weeks including all possible delays. The MARUNA risk management analysis is realized focusing in analyses of risk case scenarios for the critical activities and accordingly for each of the critical paths. Risk case scenarios have been anticipated and accordingly solution for such cases to use resources from noncritical activities has been estimated. The risk management scenarios have been closely interrelated with PERT pessimistic time calculations and reviewed and checked for compatibility of data. Risk management analysis for the first critical path CP: Requirement Analyses ) Change of requirement Human factor If Case happens then resources from activity (System Design) will be used to solve in additional If Case happens then resources from activity 0 (Write data entry) will be used to solve in additional 0 Write Program Specs ) Specification forgotten to be added Lack of time For Case resources from activity 0 (Create Data files) will be used to solve in additional week. For Case resources from activity 0 (Write data entry) will be used to solve in additional 70 Construct Programs ) Error construct programs Additional specification For Case resources from activity 0 (Write data entry) will be used to solve in additional For Case resources from activity (Test Hardware) will be used to solve in additional week. 80 Unit Testing ) Change of requirements Additional specification For Case resources from activity 0 (Detailed Design) will be used to solve in additional For Case resources from activity 0 (Create Help docs) will be used to solve in additional week. 0 Acceptance Testing ) Change of requirement For Case resources from activity 00 (Implementation) be used to solve in additional Risk management analysis for the second critical path CP: 0800 System Design Risk cases ) Change of requirement Latency in time For Case resources from activity 90 (Integration Testing) will be used to solve in additional week. For Case resources from activity 00 (Implementation) will be used to solve in additional 0 Write data entry Risk cases ) Error in design Latency in time For Case resources from activity 0 (Detailed Design) will be used to solve in additional For Case resources from activity 0 (Create Help docs) will be used to solve in additional week. Test Hardware ) Human factor For Case resources from activity 0 (Create Data files) will be used to solve in additional week. 80 Unit Testing ) Change of requirements Additional specification For Case resources from activity 0 (Detailed Design) will be used to solve in additional For Case resources from activity 0 (Create Help docs) will be used to solve in additional week. 0 Acceptance Testing 0 TEM Journal Volume / Number / 0.

6 ) Change of requirement For Case resources from activity 00 (Implementation) will be used to solve in additional 7. Forming Quality Project Team After the Risk Management Plan has finished the Team Staffing Plan can start based on the Risk Management report. In the beginning each activity is assigned a Team leader by choosing the best expert in that activity. The team leader after the risk Management report is final is posting to all members the list of all the primary and secondary skills (if they are supposed to help to another activity) necessary for this activity as well as secondary if the activity is planned to help with its resources in some critical activity. Based on the posted list of skills members are chosen for each activity. Those members that in secondary skills are missing experience a training plan is devised from the team leader and delivered to the project manager before the project actually starts. 8. Conclusion This study attempted to resolve some of the definitional and methodological difficulties encountered by previous researchers. It involved the development of a risk management model called MARUNA that connects all the stages of the project planning. This study systematically tested the correlation between critical activities and critical paths and risk scenario case management applied in project planning since its early beginning up to end. Despite the review of considerable published literature on the risk management for ICT software projects and their frequent failure did not discover a satisfactory Risk Management framework and model specific to ICT software projects. Therefore a research study was realized and as result a MARUNA risk management model was created. It connects all the stages of the project planning starting from the calculation of the most likely time for finishing a project, finding critical activities, critical path, and then optimistic and pessimistic times in order to calculate the Time of delivery of the software project. Afterwards once we have all this data the is connecting with all this data and creating risk scenario cases for all critical paths and devising a solution scenario based on all assessed risks scenarios. Once the risk management plan is finished this is used to form effective and quality project teams by using the data from previous analyses. The results of applying the MARUNA Risk Management Model has been tested with different student working groups in the framework of the subject Software Project Management and Software Engineering and we have concluded that it showed highly organized ability for working and improved attention and concentration, which can be seen from the progression in the obtained new knowledge from the staff training. The findings and recommendations are derived from the extensive body of evidence collected, in both written and oral form, from more than 70 individuals, encompassing senior directors, managers, project managers and software engineers from the public and private sector, as well as academic experts. Therefore recommended is the use of the MARUNA risk management model when undertaking ICT projects since it integrates all the project planning stages and can provide better results for use as new subjectmatter is explored; and facilitate review of main planning issues and essential details for time of delivery, critical paths, assessing risks and creating ready procedures for each anticipated risk scenario and finally creating quality teams based on the risk management plan and calculations from the time estimations. References [] Chris Sauer and Christine Cuthberts (00) The State of IT Project Management in the UK, Templeton College, Oxford, November 00 [] Dynamic Markets Limited, (007), IT project failure, Online: ndependant_markets_research_report.pdf [] Jiang, J., Klein, G. and Ellis, T. S. (00a). A Measure of Software Development Risk, Project Management Institute,, 0. [] McManus, J. (00). Risk in Software Projects, Management Services,, 0. [] Meyer, A. D., Loch, C. H. and Pich, M. T. (00. Managing Project Uncertainty: From Variation to Chaos, MIT Sloan Management Review,, 07. [] Schwalbe, K. (000) Information technology project management, Cambridge USA. [7] Weston, F. C. (00). ERP implementation and project management, Production and Inventory Management Journal,, 780. Corresponding author: Bekim Fetaji Institution: South East European University, Computer Sciences, Ilindenska bb, 00 Tetovo, Macedonia b.fetaji@seeu.edu.mk TEM Journal Volume / Number / 0. 07