IT Project Success and Failure - Essay Example

? Success and Failure of Projects Supervisor] Success and Failure of Projects Introduction Software in today’s world controls almost every aspect of our life. Software can be seen as the tool that aids us in our daily activities. The development of software is a crucial process that requires a great deal of planning and involves making some crucial decisions. One such decision that project managers have to make is deciding upon the methodology that they would adopt in order to make sure that the project is completed in the given time, budget and performs the functions that the stakeholder wants it to perform. Two such approaches that have been widely used by development teams across the globe have been Waterfall method and agile methodology. Both approaches possess their own features and both have a certain set of drawbacks. Another phase of planning that project managers have to carry out is ensuring that risk that is associated with the project is thoroughly assessed and steps are taken for the mitigation of those risks. Steps that are taken to mitigate risks associated with the project fall under the category of risk management. This paper would critically evaluate the two approaches and in the end submit recommendations that would help in deciding which approach is better to be used for the development of software. This paper would also discuss the exact role risk management plays in the development of any project. Risk management is a field of study that helps ensure that unforeseen threats to not cause any disturbances with the progress of the project. Overview of methodologies Waterfall methodology: Waterfall methodology was introduced by Winston W. Royce to the world of software development after which it has been widely used by a number of projects. Waterfall approach uses a number of phases through which the project goes through. The approach is a sequential one and one phase comes after another (Waldt & Fox, 2007). The name waterfall is coined from this sequential approach and just as the waterfall moves in one direction so does this model. Phases in the waterfall model vary from project to project however, the most projects start with requirement analysis, followed by design, implementation, testing deployment and finally its maintenance (Waldt & Fox, 2007). Requirement analysis Requirement analysis phase of the model allows developers to thoroughly obtain the details of the project and try to comprehend the objective that the project would try to achieve. Requirement analysis of waterfall methodology is one of the most crucial stages of all. The objectives and requirements have to be clearly defined before the project can be started (Waldt & Fox, 2007). Design Under design phase, developers tend to develop the basic architecture of the software. Design phase also helps determine what approaches are going to be made by the development team in order to achieve the desired result (Waldt & Fox, 2007). Implementation Implementation phase is the phase where the actual software is developed. The entire coding and documentation related to the software is created during this phase. The planning that is done during the design phase is worked on during this phase (Waldt & Fox, 2007). Testing As the name suggests the testing phase is used to test the product that is developed during the implementation phase. Small bugs within the code are removed and it is ensured that the results provided by the software are accurate. Two types of testing are carried out white box and black box testing (Waldt & Fox, 2007). Installation The software is installed in the system for which it was created under the installation phase. With the achievement of success during the testing phase the installation phase is implemented (Waldt & Fox, 2007). Maintenance Maintenance phase allows developers to regularly check up on the software and make sure it does not cause any problems. Additional updates or patches that are needed are installed under this phase (Waldt & Fox, 2007). Agile methodology: Agile method on the other hand is not divided into phases but uses an incremental approach to project management. Agile methodology usually is used in an environment where requirements of the project are hazy and unclear. Under agile methodology, individuals break down large complex tasks into a number of smaller simpler tasks that are easy to solve and handle (Highsmith, 2002). The implementation of agile methodology also does not require long term planning and focus of the project team always remains on short term objectives that are achieved within an iteration that lasts from a week to four weeks. All the team members of the project in agile development simultaneously work on different functions of the project i.e. they work on design, implementation and testing all at once and move between these functions frequently. At the end of each iteration, part of the project is completed and the results of that iteration are presented to the main stakeholder of the project (Highsmith, 2002). The stakeholder decides if the developing team is moving in the correct direction or not. This process greatly helps developers understand if the work that they are doing is correct or not. This process decreases the risk of rejection from the stakeholders. Moreover this helps include any changes within the project at any time during the development of the project. With each iteration the project moves towards the final product (Highsmith, 2002). Usually in large scale projects there are a number of there are a number of stakeholders that are genuinely interested in its success. In such a situation one stakeholder is selected who acts on behalf of all the other stakeholders. The stakeholder is the one to whom the project development consults after the end of an iteration. The stakeholder that is selected is made to make a personal commitment where he gives time to the project and is available when called upon by the development team. After iteration the stakeholder reviews the basic objective of the project and makes sure that the iteration is aligned with the objective of the objective set by the stakeholders (Highsmith, 2002). Difference between the two approaches Waterfall method as mentioned above is a sequential approach and once a phase in waterfall method is completed the development team cannot make any changes to any of the previous phases. This makes the model very rigid and for this reason it cannot accept changes very easily. If amendments are made to the initial requirements of the project then the entire project has to go through all the phases again just adjust one single change within the project. Agile method on the other hand can easily adapt at any stage of the project and initial requirements of the project can even be altered. With agile methodology there is no need to design and entirely new approach to the project development. Not only changes but the upgrades can also be accepted by the approach (Millett et al., 2011). Testing phase within a waterfall methodology can be time consuming and costly as the errors of the entire approach are caught at almost the end of the project which means that to rectify those errors the project team has to go through all the initial steps again, wasting time and money. In agile methodology however, testing is carried out after each module or each iteration, which means that little time and money is wasted in the testing of the project (Millett et al., 2011). Waterfall method works on a strict schedule and careful planning is conducted before the start of the project. The start and end date of each phase is known prior to its start and developing teams are able to manage themselves in accordance to the deadlines that are provided to them regarding each phase. In agile methodology since requirements of stakeholders change at a regular basis it is difficult to determine exactly when the project is going to end. The developing team cannot give a definite date of completion of the project or of when there would be a final product ready for use (Millett et al., 2011). Critical analysis: Initially there was only waterfall method that was used by organizations to solve their software related problems. Debate between waterfall and agile started only a few decades back. There are valid arguments put forward by supporters of both methodologies. If development teams are unaware of which methodologies they should opt for it is best that they should stick to waterfall methodology by default (Hughes & Hughes, 2008). Waterfall is a well-structured and comprehensive approach that provides developers with an opportunity to work as a team and at an organizational level (Hughes & Hughes, 2008). The question then in turn arises that when should a development team opt for an agile approach to ensure successful completion of the project. As mentioned above agile methodologies work best if the stakeholders are unsure of exactly what they want out of the system that they are getting developed or if the system would require regular updates in anytime during the development of the software solution. What’s more agile development approach can only be implemented if the team comprises of experienced personnel. With all the changes being made to the requirements it could easily get confusing for a novice team and handling the project can become much more difficult. Lastly there is an issue of time, if stakeholders have not placed any restrictions on the time of delivery of the project then agile would be a better suited option over waterfall methodology (Zain et al., 2011). The two approaches of the waterfall model and agile methodology are considered completely opposite to each other. Waterfall model is a structured and comprehensive approach that can allow developing teams to complete the development of their software with in the allocated budget and time. Waterfall is also a rigid approach and all the requirements need to be defined beforehand and in detail for the method to provide effective results for the development team. Agile methodology on the other hand works best where stakeholders are uncertain of exactly what functions they would like to see within their software. Agile methodology gives stakeholders an opportunity to make amendments to the original requirements whether the project is in its initial or final stages. However, to obtain successful results from agile methodology it is vital that a few factors must be looked into. First and foremost it is vital that there must be no budget or time constraint associated with the project. Secondly the developing team working on the project must be experienced enough to handle the changes being made. Importance of Risk Measurement Risk management in basic terms is the study of all the risks that are associated with a certain software project. Under risk management, teams study and prioritize risks in a certain order. The management also helps in studying various economical methods that help in the mitigation of risks that are identified during this process. Risk management is an integral feature of software management (Bannerman, 2008). Risk can occur in almost any area and can greatly affect the progress of the project. These risks can be associated with technology the team that is working with the technology and the environment where the software is supposed to function. All these factors are carefully studied and their probability of occurrence is also calculated (Lee, 2012). Calculating risk is basically carried out under the supervision of the project manager. Risk can be calculated using certain variables and calculated values such as loss hours, risk hours, previous risk hours and contingency plan. Loss hours represent the number of hours that is loss due to the occurrence of a particular risk. Risk hours represented the value of risk that is associated with a certain risk and can be calculated by multiplying risk hours with the probability of the occurrence of an event. The term previous risk hours is a value that represents risk hours that were calculated for a risk in the first attempt. Any change in the risk hours is recorded using this variable. Finally the contingency plan represents the preventive measures that are taken by the development team in order to completely avoid a risk from occurring or mitigating the effects of a risk (Lee, 2012). The efficiency of risk management can be used to measure using certain factors that are known as Key Performance Indicators (KPI). KPIs are monitored throughout the project to ensure that a certain situation does not reach the critical mark. If in case a KPI does reach critical status then the team must revert to a contingency plan (Ramachandran, 2011). Risk management within the development and successful completion of a project plays a crucial role. A development team can only carry out risk management when it understands that risk is associated with all projects and its mitigation is an essential part of the project (McManus, 2004). The first major importance of risk management is that it allows the development team to understand and identify all the areas where risk there is the risk associated with. With the identification of risk the development team becomes mentally aware of the events or procedures that might go wrong during the development of the project. Accurate and efficient identification of risks allows the development team to identify every risk there is (McManus, 2004). The second important factor that risk management helps with is with understanding the exact impact that a particular risk would have on the project. The magnitude of impact a particular risk can have on the project. With this knowledge in their minds focus of the development team shifts to one of the most vulnerable aspects of the entire project development phase (McManus, 2004). Two of the greatest factors that attribute to the incompletion of a project are time and cost. Project managers are usually unable to contain the cost of developing the project or are unable to meet the deadline of the project (Karolak & Karolak, 1995). It is estimated that more than 50 percent of projects are delivered late or are cross the budget allocated to them 25 percent of overall projects fail because delay in its delivery or the cross benefit ratio of such projects no longer seems feasible after the readjustment of the budget. A small portion of the 25 percent fail because these projects weren’t provided the required resources majority of them occur because of foreseeable circumstances. The rest of the 25 percent fall under the category of projects that are completed on time and within the allocated budget (Thomsen & Hansen, 2004). As mentioned before risk management helps significantly in mitigating any risks that threaten the progress of the project. With the use of risk management not only can get the work done in the allocated budget but can also ensure that the project is completed in the duration that was initially agreed upon. However, the implementation of risk management is not enough, risk management and analysis has to be efficient enough to help the development team locate every area where the project might be vulnerable (Karolak & Karolak, 1995). Conclusion Findings: The research conducted in this paper shows that the benefits of implementing agile methodology are greater than that of the waterfall model. However, the implementation of agile methodology is not as simple as that of the waterfall methodology. There are a number of factors that need to be taken into account before its implementation. Agile methodology can only be successfully implemented if the development team comprises of experienced individuals who have worked on agile methodology before. Team members that have little experience in working with agile methodology would most likely get confused with the continuous changes that are made to the initial requirements of the project. With waterfall model however, less experienced individuals can operate easily as the formal structure of the waterfall model acts as a guideline for individuals. Before a development team could work on a project it is important that they understand that there are always certain risks associated with a project. In order to mitigate those risks it is important that development teams plan ahead and implement efficient risk management processes within their project. The inclusion of the process of risk management in software development is not only recommended, but is also considered mandatory by some experts. They consider an efficient risk management phase as crucial to the success of a project. Poor risk management practices or omitting risk management from the development phases of project management is considered as a grave mistake and in most cases it becomes one of the factors that lead to the failure of the complete project. Recommendations: As mentioned before when it comes to choosing between waterfall and agile methodology it is best if development teams stick to waterfall method as their default model. Waterfall model may be a rigid model but it provides the development team with a structured approach in which the team can coordinate with each other in a formal manner. The only conditions in which organizations should opt for agile methodology is if there are no budget constraints nor is time the issue with the stakeholders. Furthermore, agile to implement agile methodology experienced individuals should be at the development team’s disposal and the requirements of the stakeholders are not clear or are changing with time. The literature that is presented states it clearly that risk management is one of the most integral phases that the development team has to work on. Risk management is one aspect of project management that cannot be omitted. The project manager must directly take responsibility of ensuring that all basics are covered when it comes to risk management. Moreover proper calculated approach needs to be taken where data is converted into numbers and numbers are analysed to reach a certain result. Key Performance Indicators should be used to monitor the status of a certain risk. KPIs should be measured at a regular interval and any changes within KPIs should be reported to the project manager. In a case where a KPI reaches critical levels the project manager should implement contingency plan. List of References Bannerman, P.L., 2008. Risk and risk management in software projects: A reassessment. The Journal of Systems and Software, pp.2118-33. Highsmith, J.A., 2002. Agile Software Development Ecosystems. Indianapolis: Addison-Wesley Professional. Hughes, T. & Hughes, C., 2008. Professional Multicore Programming: Design and Implementation for C++ Developers. New York City: John Wiley & Sons. Karolak, D.W. & Karolak, N., 1995. Software Engineering Risk Management: A Just-in-Time Approach. Los Alamitos: IEEE Computer Society Press. Lee, R., 2012. Software Engineering Research, Management and Applications 2011. Mt. Pleasure: Springer. McManus, J., 2004. Risk Management in Software Development Projects. London: Routledge. Millett, S., Blankenship, J. & Bussa, M., 2011. Pro Agile.NET Development with SCRUM. New York City: Apress. Ramachandran, M., 2011. Knowledge Engineering for Software Development Life Cycles. London: Idea Group Inc. Thomsen, C. & Hansen, J.E., 2004. Enterprise Development with Visual Studio.NET, UML, and MSF. New York City: Apress. Waldt, G.V.D. & Fox, W., 2007. A Guide to Project Management. Cape Town: Juta and Company Ltd. Zain, J.M., Mohd, W.M.W. & El-Qawasmeh, E., 2011. Software Engineering and Computer Systems, Part I. New York: Springer. Read More