A Framework for Identifying and Understanding Risks in Information Technology Projects

Managing the costs, complexity, and risks of IT projects continues to be a challenge for many organizations. Project risk management is becoming an important sub-discipline of software engineering, and focuses on identifying, analyzing, and developing strategies for responding to project risk efficiently and effectively. This paper presents an IT project risk identification framework to facilitate identifying and understanding various project risks as part of an overall project risk management process. The proposed framework should be of interest to IT practitioners during the creation of the project plan and over the course of a project so that appropriate and corrective actions can be taken as needed. Moreover, this risk identification framework should also be of interest to IT academics in terms of teaching project risk management or as a theoretical basis for future research. Taken together, this may help increase the likelihood of IT project success

Additional Costs And Risks In Software Acquisition Projects

Organizations usually contract their software projects to avoid the risks associated with developing the software internally and to control their costs. However, a study of two-dozen contracted project indicates that such organizations face unique risks and hidden costs that are particular to software aquisitions.  This paper describes research done to estimate the effort expended by organizations in overseeing and participating in contracted software projects and the implications for predicting costs and identifying risks of such projects. It presents a framework for collecting and measuring costs incurred before, during and after the contract award. For many of the organizations that participated in the survey, realizing the actual costs and  risks of a project was an eye opener – hidden costs and risks  are significant and they are typically not managed.  The research results emphasize  the need for institutionalizing processes for the collection of data about contracting costs within an organization so that databases of metrics about completed projects can be built and later used to forecast costs for future projects to improve decision-making processes. The research results also emphasize the need to acknowledge the risks involved so  they can be mitigated to improve the relationship with the contracor and the chances for project success. The authors are engaged in research directed toward assisting such organizations in identifying the risks and costs and improving the acquisition process. &nbsp

Towards Knowledge Based Risk Management Approach in Software Projects

All projects involve risk; a zero risk project is not worth pursuing. Furthermore, due to software project uniqueness, uncertainty about final results will always accompany software development. While risks cannot be removed from software development, software engineers instead, should learn to manage them better (Arshad et al., 2009; Batista Webster et al., 2005; Gilliam, 2004). Risk Management and Planning requires organization experience, as it is strongly centred in both experience and knowledge acquired in former projects. The larger experience of the project manager improves his ability in identifying risks, estimating their occurrence likelihood and impact, and defining appropriate risk response plan. Thus risk knowledge cannot remain in an individual dimension, rather it must be made available for the organization that needs it to learn and enhance its performances in facing risks. If this does not occur, project managers can inadvertently repeat past mistakes simply because they do not know or do not remember the mitigation actions successfully applied in the past or they are unable to foresee the risks caused by certain project restrictions and characteristics. Risk knowledge has to be packaged and stored over time throughout project execution for future reuse. Risk management methodologies are usually based on the use of questionnaires for risk identification and templates for investigating critical issues. Such artefacts are not often related each other and thus usually there is no documented cause-effect relation between issues, risks and mitigation actions. Furthermore today methodologies do not explicitly take in to account the need to collect experience systematically in order to reuse it in future projects. To convey these problems, this work proposes a framework based on the Experience Factory Organization (EFO) model (Basili et al., 1994; Basili et al., 2007; Schneider & Hunnius, 2003) and then use of Quality Improvement Paradigm (QIP) (Basili, 1989). The framework is also specialized within one of the largest firms of current Italian Software Market. For privacy reasons, and from here on, we will refer to it as “FIRM”. Finally in order to quantitatively evaluate the proposal, two empirical investigations were carried out: a post-mortem analysis and a case study. Both empirical investigations were carried out in the FIRM context and involve legacy systems transformation projects. The first empirical investigation involved 7 already executed projects while the second one 5 in itinere projects. The research questions we ask are: Does the proposed knowledge based framework lead to a more effective risk management than the one obtained without using it? Does the proposed knowledge based framework lead to a more precise risk management than the one obtained without using it? The rest of the paper is organized as follows: section 2 provides a brief overview of the main research activities presented in literature dealing with the same topics; section 3 presents the proposed framework, while section 4 its specialization in the FIRM context; section 5 describes empirical studies we executed, results and discussions are presented in section 6. Finally, conclusions are drawn in section 7

Risk Profiles in Individual Software Development and Packaged Software Implementation Projects: A Delphi Study at a German-Based Financial Services Company

The aim of this paper is to compare risk profiles of individual software development (ISD) and packaged software implementation (PSI) projects. While researchers have investigated risks in either PSI projects or ISD projects, an integrated perspective on how the risk profiles of these two types of information system (IS) projects differ is missing. To explore these differences, this work conducted a Delphi study at a German-based financial services company. The results suggest that: First, ISD projects seem to be more heterogeneous and face a larger variety of risks than the more straightforward PSI projects. Second, ISD projects seem to be particularly prone to risks related to sponsorship, requirements, and project organization. Third, PSI projects tend to be predominantly subject to risks related to technology, project planning, and project completion. Finally, in contrast to available lists of risks in IS projects and irrespective of the project type, the paper found a surprisingly high prominence of technology and testing-related risks

Designing a consulting services architecture model

textDuring my years of experience in the technology industry, it has become obvious that standard processes and methodologies within the engineering discipline are at a mature state. The realization though is that software engineering specifically lags behind. Most software engineering methodologies that I have studied focus on the mission of software development. It is this realization and the need for structure that led me to review existing methodologies used within my company's software services organization. The definition of what a successful software services methodology entails is rather limited. This report will provide a history of existing software engineering methodologies that I have studied, describe an initial services method that was being developed within my organization, develop a new model that addresses previous shortcomings and identify additional components required to further define a strong software services-oriented delivery methodology.Electrical and Computer Engineerin

Real world evaluation of aspect-oriented software development : a thesis submitted in partial fulfilment of the requirements for the degree of Master of Science in Computer Science at Massey University, Palmerston North, New Zealand

Software development has improved over the past decade with the rise in the popularity of the Object-Oriented (OO) development approach. However, software projects continue to grow in complexity and continue to have alarmingly low rates of success. Aspect-Oriented Programming (AOP) is touted to be one solution to this software development problem. It shows promise of reducing programming complexity, making software more flexible and more amenable to change. The central concept introduced by AOP is the aspect. An aspect is used to modularise crosscutting concerns in a similar fashion to the way classes modularise business concerns. A crosscutting concern cannot be modularised in approaches such as OO because the code to realise the concern must be spread throughout the module (e.g. a tracing concent is implemented by adding code to every method in a system). AOP also introduces join points, pointcuts, and advice which are used with aspects to capture crosscutting concerns so they can be localised in a modular unit. OO took approximately 20 years to become a mainstream development approach. AOP was only invented in 1997. This project considers whether AOP is ready for commercial adoption. This requires analysis of the AOP implementations available, tool support, design processes, testing tools, standards, and support infrastructure. Only when AOP is evaluated across all these criteria can it be established whether it is ready to be used in commercial projects. Moreover, if companies are to invest time and money into adopting AOP, they must be aware of the benefits and risks associated with its adoption. This project attempts to quantify the potential benefits in adopting AOP, as well as identifying areas of risk. SolNet Solutions Ltd, an Information Technology (IT) company in Wellington, New Zealand, is used in this study as a target environment for integration of aspects into a commercial development process. SolNet is in the business of delivering large scale enterprise Java applications. To assist in this process they have developed a Common Services Architecture (CSA) containing components that can be reused to reduce risk and cost to clients. However, the CSA is complicated and SolNet have identified aspects as a potential solution to decrease the complexity. Aspects were found to bring substantial improvement to the Service Layer of SolNet. applications, including substantial reductions in complexity and size. This reduces the cost and time of development, as well as the risk associated with the projects. Moreover, the CSA was used in a more consistent fashion making the system easier to understand and maintain, and several crosscutting concerns were modularised as part of a reusable aspect library which could eventually form part of their CSA. It was found that AOP is approaching commercial readiness. However, more work is needed on defining standards for aspect languages and modelling of design elements. The current solutions in this area are commercially viable, but would greatly benefit from a standardised approach. Aspect systems can be difficult to test and the effect of the weaving process on Java serialisation requires further investigation