A STUDY ON

IT PROJECT RISK ASSESSMENT

By

12030241079

Mayur Kamalakant Pawar

Information Security

MBA (2012-14)

Symbiosis Centre for Information Technology

(a constituent member of SIU Established under section 3 of the UGC Act 1956

vide notification No. F.9-12/2001-U.3 of the Government of India)

2

ACKNOWLEDGEMENT

It is my great pleasure to present my work on IT Project Risk Assessment. I would like to

take this opportunity to thank my mentor Prof. Pradnya Purandare, for her valuable

guidance throughout the project.

I also thank all Lab members and the faculty members of SCIT for their support. I would like

to thank all my colleagues at SCIT. Many ideas that resulted in the research and presented in

this report had their origins in discussions.

I would like to sincerely thank our Director Dr. R. Raman, Symbiosis Centre for

Information Technology, Pune, for guiding me and inculcating a research culture in our

academic course.

3

CONTENTS

CHAPTER ONE ..................................................................................................................................... 4

Topic ................................................................................................................................................... 4

1.1 Abstract ................................................................................................................................... 4

1.2 Introduction ............................................................................................................................. 4

1.3 Scope ....................................................................................................................................... 5

1.4 Objective ................................................................................................................................. 6

CHAPTER TWO .................................................................................................................................... 7

2.1 Review of Literature ............................................................................................................... 7

CHAPTER THREE ................................................................................................................................ 9

3.1 Analysis of problem under research ........................................................................................ 9

3.2 Alternative Solutions and their advantages & disadvantages ............................................... 10

3.3 Proposed Solution ................................................................................................................. 13

3.4 Technical Justification of the Solution .................................................................................. 14

3.5 Technical Environment and Technical Details ..................................................................... 16

3.6 Possible Applications in the Industry .................................................................................... 17

CHAPTER FOUR ................................................................................................................................. 18

4.1 Findings................................................................................................................................. 18

4.2 Recommendations ................................................................................................................. 20

4.3 Conclusion ............................................................................................................................ 20

REFERENCES ..................................................................................................................................... 21

Figure. 1 General process flow - Brainstorming & Evaluation

Figure. 2 Sample output of a quantitative risk model

Figure 3 PEST Analysis

4

CHAPTER ONE

Topic

IT Project Risk Assessment

1.1 Abstract

Every IT project undertaken whether on an organizational or government level has always

carried an innate risk with itself. Ideally, an IT project should be planned and executed in

such a seamless way that the uncertainty of its outcomes should be zero. However, this is far

from being the reality. Risks can be due to anything be it the risk of infrastructure failure,

financial failure or something as negligible as a power failure. The current IT scenario is a

very dynamic one with new technologies coming up in a short time. Technologies such as

Cloud, Big Data, the rise of mobile devices etc. have brought new found flexibility and

productivity in the way IT projects were completed. But with this changing landscape, there

are some new found risks which threaten the way IT projects were executed.

Traditionally, there have been different IT project risk assessment methodologies been

adopted currently. However, many of these methodologies are not adopted in real life project

scenarios due to various reasons. This research precisely focusses on the types of risks

generally associated currently with IT projects, the risk assessment methodology suggested

theoretically and the currently adopted risk assessment methodologies.

1.2 Introduction

Information technology has been playing an important role in the success of a lot of non IT

companies. There have been so many cases where full-fledged IT projects have been rolled

out for companies from different sectors such as retail, pharma, aviation etc. The reason for

flawless execution of these projects is successfully assessing the risks associated with them.

Risk management has become a key factor within organizations since it can minimize the

probability and impact of IT project threats and capture the opportunities that could occur

during the IT project life cycle.

5

A risk is an event, which has to innate properties [1]

- Uncertainty

- Has a negative impact in some way on the project

For example, to a life insurance company the timing of deaths of its policyholders are risks.

The company never knows precisely who among their insurees is going to die in a given

period of time (uncertainty) and each death costs them a payout equal to the face value of the

policy (negative impact on profitability).

Risk analysis is the process of quantitatively or qualitatively assessing risks. This process

involves an estimation of both the uncertainty of the risk and its impact.

For instance, an insurance company can estimate the number of deaths in a given period

based on demographic information about their insurees; this estimate along with information

about their policies, in turn allows them to estimate the amount of money they will have to

pay off in the time period in question. In general, these estimates will not match the exact

amount of money paid out, but a key part of the uncertainty analysis will allow the insurance

company have an idea of how likely different payoffs are in a range around their estimate.

Risk management is the practice of using risk analysis to formulate management policies to

counter risk. In order to deal with an estimated payoff, the insurance company may take

certain measures such as revising its investment strategy, the eligibility for claiming

insurance etc.

While different risk assessment methodologies are advocated by theorists, there are altogether

different methods applied in real life project scenarios. Currently much has been said and

written on the risk assessment methodologies established theoretically. These methods are

adopted by full-fledged IT companies who handle complex IT projects. But there is general

lack of literature for how these risk assessment techniques are applied to IT projects for small

and medium scale enterprises. As a result of this, there is huge gap in the risk assessment

methodologies being advocated as theories and the ones being applied actually, especially in

the companies in the SMB sector. Also, selection of a risk assessment technique depends on

several factors. [2] These factors are different for different companies depending on the type

of project and the risk scenario of that domain.

1.3 Scope

Currently the scope of this research is limited only to the projects undertaken by IT

companies. These projects can be from any domain but essentially they have to be IT

projects. This paper will concentrate more on the IT companies which are in the startup phase

in comparison to the well-established, more robust multinational companies.

6

1.4 Objective

The objective of this paper is to highlight the gap in the risk assessment methodologies

currently accepted by the industry and the pedagogical methods of risk assessment. In

addition to this basic objective, this paper also intends to find answers to other questions such

as

- How do Project Managers handle risks and uncertainty associated with different types

of projects?

- What factors of a project are taken into consideration while handling risks associated

with it?

- What do Project Managers understand by success of a project? What are the factors

which influence the success of a project?

- Is changing the risk assessment methodology beneficial for the organization?

- Do Project Managers believe in changing the risk assessment methodology according

to the IT project? If yes, then what are the factors which influence their decision?

- Understanding the way industries in the SMB sector adapt risk assessment

methodologies in comparison with the multinational companies

1.5 Methodology

The methodology adopted in this research paper is a case based approach. Business cases

describing the way IT projects are implemented in multinational IT organizations will be

studied in contrast with the way IT projects are handled by IT startups. Risk assessment

methodologies generally adopted across the IT industry will be discussed after interviewing

executives from the multinationals and the IT startups. Accordingly emphasis will be given

more on the qualitative data and understanding the spectrum of approaches adopted by the

executives.

7

CHAPTER TWO

2.1 Review of Literature

Supporting this research, in order to provide a background for identification of a research

gap, formulating a research problem and then taking this analysis ahead a comprehensive

literature review was conducted. Research papers, journals and other material were used as

evidential references. This review addresses the key terms, definition, challenges regarding

the risks associated with IT project environments both in an established IT setup and in IT

projects in a start-up phase.

It is a widely accepted fact that IT projects have failed historically and continue to fail. A few

notable projects which have failed are as follows [3]:

- FoxMeyer Drugs a company worth $5 billion and the 4th largest distributor of

pharmaceuticals in the US decided to increase its efficiency. Hence in 1993, they

purchased a SAP system and a warehouse automation system and hired Anderson

Consulting to implement and integrate it. By 1996, the company went bankrupt and

was sold to a competitor for a mere $80 million.

- Sainsbury the British supermarket giant suffered losses of 150 million in IT costs

when it decided to scrap its project of installing an automated fulfilment system at its

Waltham Point distribution centre in Essex. The system, after installation, began

giving horrendous barcode reading errors which have crept up to such an extent that

the company decided to scrap the project.

- The FBI Virtual Case File this high profile project of upgrading its IT infrastructure

and automating its case management system was a complete failure thanks to faulty

design requirements, an over-the-top and too ambitious time frame and an overall lack

of planning for purchasing and deployment. An initial project budget of $379.8

million bludgeoned adding another $123.2 million for the project resulting into

scrapping of the project for good.

- The DMV Projects two US states, California and Washington suffered huge

financial losses to the tune of $49 million when their project of attempting to

computerize their departments of motor vehicles failed miserably after execution. The

new system was slower than the one which was designed to replace. At the same time

there was a problem of vendor locking with the state being forced to buy hardware

from the same vendor.

Many more examples like these can be found in the current IT landscape having much more

bigger impacts. So it becomes an utmost necessity that these failures cannot be ignored.

Lessons need to be learned from them to avoid the same mistakes in the future by having a

risk mitigation plan.

8

The gamut of effective IT project management has been receiving enough attention from

academicians since 1978 [4]. Over the years, different risk assessment methodologies have

been suggested by the practitioners, but not all methodologies received widespread

acceptance. Project managers continue to see risk assessment and management as an

important activity only because the project management handbooks say so. Without

understanding the technicalities of the project, they tend to apply the same risk management

methodologies across different projects thus ending up with failures.

Though researchers have had a common interest concerning risk and uncertainty in IT

projects, each one has come up with a different perspective of handling an IT project. For

instance, early authors such as Alter and Ginzberg viewed handling risk as a post-evaluation

process [5]. Whereas, the current scenario advocates having a more flexible risk assessment

and management approach due to the dynamic nature of technology. We cannot have a rigid

risk assessment model since IT has been a major driver for a lot of businesses across different

sectors.

Gemmer (1997) [6] advocates that effective risk management requires functional behaviour

of the stakeholders. This means that they may not necessarily comply with the risk

management procedure. On the other hand Dey et al. (2007) [7] affirms that a projects

success or failure depends generally on the stakeholders involvement in the risk management

process [8].

However, these are methodologies which are advocated by the theorists and academicians. In

practical implementation of IT projects there is not a single risk assessment approach which

is followed. The type of approach depends on several factors and some of these factors are a

prerequisite for a good risk assessment methodology to be followed. [2]

Also little has been written on how IT companies in the startup phase approach risk

assessment for a particular project vis--vis IT multinational companies formulating

strategies to measure uncertainty and risk.

The sections that follow up in this paper slowly progress in the direction of finding the most

common reasons of an IT project failure [9], ways to handle these issues with a focus on

different factors such as project complexity, domain knowledge, management of risk and

perceived project success.

This paper will also analyse two cases one of a startup IT Company and one of a well-

established IT multinational player how these companies have different approaches for risk

assessment.

9

CHAPTER THREE

3.1 Analysis of problem under research

Information systems fail very often. And there is nothing wrong in it. It would be very nave

of us to believe that a fool proof system exists. It should be understood that however carefully

the system might be built there is always a chance of it failing. At the same time it should

also be noted that this should not be an excuse to come up with a shoddily designed system.

What constructive can be done is to learn from these mistakes by first understanding the root

cause of the failure. Accordingly, measures can be taken to overcome those flaws, which if

they are successful, can be adopted as a standard practice across different projects in different

domains.

The problem under consideration is concerned with IT Project risk assessment

methodologies. Whether the generally accepted risk assessment pedagogical methods are

actually put to use in the real IT scenario or if they are not, then how are risks associated

with real life IT projects assessed. However, unless there is a clear understanding of the

reasons behind a project failure it is useless to discuss the risk assessment methodologies

associated with it.

Considering this scenario, in the section to follow common reasons why an IT project fails

are highlighted. [9]

Lack of a specific methodology because coding is what matters

Having a structured systems development methodology is very important in a systems

development project. Without having a specific methodology in place just punching in the

code is not taking the project anywhere. There are different industry wide methodologies

such as CASE and the CASE Application Development Method (CADM) which takes care of

many quality control points thus making the whole process a near flawless one.

Creating a project plan working backwards from a tight system completion date

Working backwards from a drop dead system completion date is a sure shot way of ending

the project on a failure note. Still its very much prevalent in the current IT scenario.

Managers tend to fix a date to roll out a new system in the production environment without

even knowing the technical details such as the number of resources required to finish that

task.

Building tables ignoring the data models

Data models need to be built right in the beginning of the project under the direct supervision

of the technical team leader. The data model is the core of any system. Without

understanding the core component it is very difficult to meet the user requirements which

mean that the project is heading towards a complete failure.

10

Using a technical lead that has never built a similar system

Not hiring an experienced technical lead that has handled similar projects just because it is

expensive does not qualify as a good reason when the project success is concerned. Of

course, such a resource is quite expensive - not nearly as expensive as a failed project, but

still expensive. It is wise to incur some extra cost on hiring experienced personnel to see this

project through instead of failing it by hiring a battery of inefficient programmers.

Not using the right tool for the right job

Tools, if not used judiciously have the ability to turn a relatively smooth going project upside

down. For instance, there is no point using a particular technology if there are no plans for

further expanding the product into that direction.

Skipping the testing phase because the project is way behind schedule

Putting a system directly into production without testing it is as risky as jumping into a

swimming pool even without even checking if there is any water in it. The time spent to

thoroughly test any system before placing it into production can save much more time in the

long run. It is not necessary that the every time a test run will yield into modifications in the

system. However, test runs ensure that the software development is on the right track as

intended in the beginning.

Buying a commercial, off-the-shelf package and customize it

To successfully use a commercial, off-the-shelf package (COTS) we have to make sure that

the software package offers all the features necessary to complete our project. It has to be

completely flexible to accommodate the ongoing requirements of the client on-the-fly. Care

should be taken that the package needs to be tweaked as per the business requirements and

not the other way.

3.2 Alternative Solutions and their advantages & disadvantages

Project Risk Assessment for IT Startups

Risk is identified in project management literature as an important factor influencing IT

projects success. The paper presents different approaches to risk assessment of IT projects in

IT startups in comparison with IT multinational companies.

IT startups have a very unique business model of targeting the niche market using a limited

set of resources. They specialise in offering services and products which are generally not

available in the market especially from the mainstream offerings. In short they are trying to

11

generate revenue using a business model which is having a fair amount of risk associated

with it. Though this is the case, most IT startups do not have a well laid out risk assessment

mechanism for their business.

For instance, Fab.com an ecommerce startup based in the US sells unique and quirky items

for men, women, vintage furniture, art items, items for pets etc. They are based in New York,

US and have their development centres in Pune, India and Berlin, Germany. Fab was founded

in February 2010 by Jason Goldberg and chief designer Bradford Shellhammer. The site was

originally created as a social network before pivoting on June 9, 2011 into its model of daily

design inspirations and sales. [10]

The software development centre employs software engineers who develop software for their

ecommerce portal after getting feedbacks from customers & their in-house team of

developers. Mostly the development work comprises of improving the efficiency of the portal

by adding new functionality modules, maintaining the online content, managing the

warehouse system etc. The business model of Fab.com is comparatively a much riskier one

than other multinational companies who have a dedicated focus on risk assessment practices.

Fab.com generates business revenues on a seasonal basis so they do not have a steady

revenue stream which is a risk they are taking. In spite of this, the company does not have a

dedicated focus on risk assessment because that is a risk they are ready to take. This is

because they operate in a niche area where the competition is low and though they do not

generate steady revenues, they still can capitalise on the seasonal business.

However the company does not completely neglect the risk assessment process. Whenever a

new product has to be introduced or a new product feature has to be rolled out, it is first

discussed and brainstormed among existing team members the feasibility check and the

ROI it is going to generate in terms of revenue, market share or even customer satisfaction.

Essentially the company follows an Evaluation Approach to IT project risk management -

From the evaluation approach, the process of risk management is an analysis for determining

the risk factors and causes of project failure. It aims to learn from past projects, by evaluating

risks that have already occurred. The evaluation may result in modifying the use of the

methodology of risk management or even changing the methodology. The contribution of the

evaluation approach of risk management to project success is indirect, as the information

gathered is used in future projects Risk Identification practice which means that risks are

named and identified by filling out questionnaires, consulting experts, doing brainstorming

sessions, conducting interviews etc.

This approach assumes that it is likely that knowledge of the risks and their causes will have

a positive impact on the project outcome. The aim of this approach is to create project

predictability in new projects by using information regarding risks and causes of project

failure gathered from previous projects.

12

Project Risk Assessment for IT multinationals

IT multinational companies have an altogether different and much more complex business

model. Often this business model has multiple aspects depending on the domain it is being

applied to. They have an underlying business model which acts as a mould for other modules

to fit in. These modules are flexible and change as per the domain the business model is

applicable to.

The risk assessment approach adopted by a multinational company depends on factors such

as the kind of IT projects the company is undertaking, the domain in which they are operating

these projects, the rules & regulations, governing mechanisms of completing these projects in

collaboration with the government and non-government agencies, the employee strength, the

geographical region of operation etc. So the risk assessment approach is subjective.

After interacting with Project Managers of different IT multinational companies, it was found

that these companies have a dedicated focus on risk assessment practices. Some of these can

be presented as

Informal direct risk assessment of risks experienced judgement

Checklists list of risks that have happened before or features of a project generally

thought to be risky

Risk indicator scales scoring schemes

Structured brainstorming and evaluation

Probability Impact calculations

Probabilistic modelling of costs, schedules and cash flows

Features of each of these practices can be summarized as follows

Method Identification and

prioritization of risks

Budget, target and

contingency settings

Informal direct risk

assessment of risks

Works well when the content

and commercial environment

of project is routine and

experienced people are

available with time to

consider each project with

depth

Rating depending on the

judgement

Checklists Works well if the latest job

goes no further than the

material used to develop the

list

No direct value except in

providing input to subjective

judgement

Risk indicator series Works as a support for

subjective judgement when

the content and commercial

environment of your project

is routine and scales have

Misused by inexperienced

personnel trying to convert

the scales into direct value

13

been calibrated

Structured and brainstorming

evaluation

Depends on the team

members for brainstorming

More effective than a single

person team

Has the capacity to develop a

360 degree view thus

ensuring a good

understanding of the solution

Probability Impact Calculations

No direct help in identifying

risks

Suffers with problems of

characterizing risks for

uncertain events with single

probability, false sense of

security

Probabilistic modelling Can be used as a framework

for risk identification and

tends to highlight any gaps in

plans and optimistic

assumptions

Provides a sound basis for

understanding uncertainty in

costs and schedules estimates

and setting realistic targets

and clarifying the effects of

alternative risk sharing

strategies Table 1 Risk Assessment Practices - Features

3.3 Proposed Solution

Ultimately risk has always been an inherent component of software development projects, as

well as other IT projects. The essence of project management is risk assessment.

Success or failure of an IT project often depends on the contributions of stakeholders: top

management, functional managers, customers, suppliers, contractors, and others. That is why

stakeholders must be involved in the risk assessment process.

All of the techniques and practices of risk management try to increase stakeholder

satisfaction and increase the chances of project success. Risk assessment should be more of a

proactive process and less of a reactive process. During the interactions with managers from

startups as well as multinational companies it was found that they believed risk analysis and

assessment and treatment of risks was a subjective affair depending on personal judgement.

Though this is the case there has to be standard process to deal with risks associated with any

project. The actual process of identifying project risks forces some discipline at all levels of

project management and improves project performance.

Of the methods discussed above, structured brainstorming and evaluation is a proven

technique for identifying risks and getting a clear view of their relative significance. It relies

on a carefully planned and executed workshop process. Some of the strengths of this method

are

Can be managed to fit into a schedule

Covers the problem systematically

Delivers cost effective output

Good use of resources

14

Probabilistic modelling can be used to complement the brainstorming technique to ensure all

significant influences on a projects cost and schedule are incorporated into a view of the

projects overall performance.

3.4 Technical Justification of the Solution

As mentioned earlier this being a qualitative study of how different types of risk assessment

methodologies are applied to IT projects, it would be vague to propose a technical

justification of the solution. However, we can delve into slightly deeper analysis of the

proposed solution structured brainstorming and evaluation.

Having experienced people in the team is a near perfect scenario of ensuring minimum risk.

We can be confident enough that there is no stone left unturned in the search for risks.

However, experienced people are generally busy and it is important to have a way to use their

time cost-effectively.

Simple structured techniques can be used to drive a project group through a focussed exercise

and produce a valuable result in a limited and predetermined time. There are different

standards available for Risk Management such as AS/NZ 4360, ISO 31000 etc. native to

specific countries as well as some internationally accepted standards such as ISO 27000, ISO

27001 etc.

Some generally accepted functional requirements for the proposed solution of brainstorming

and evaluating can be mentioned as follow [11]

Establishing the context

o Identify the risks

o Objectives

o Stakeholders

o Criteria

o Define key elements

Identify the risks

o What can happen?

o How can it happen?

Analyse the risks

o Review the controls

o Likelihoods

o Consequences

o Level of risk

Evaluate the risks

o Evaluate risks

15

o Rank and prioritize the risks

Treat the risks

o Identify options

o Select the best responses

o Develop risk treatment plans

o Implement

The different methodologies suggested above have their own pros and cons. For instance,

Informal Direct Assessment is great as far as the current IT project is the same as the earlier

one. This methodology becomes ineffective as soon as the technical content, project

complexity, commercial arrangements, resourcing strategy or other key features move into

untried waters.

Checklists are feasible to use as a final reference point. This methodology is applicable only

when you have a static list of risks. Whenever there is a dynamic list of risks, the checklists

become redundant and cumbersome to update every time a new risk is identified.

The problem with the Risk Indicator Series is that a good project can get a bad score and vice

versa. The score can be challenged by individuals with vested interests who want to see a

project go ahead or a project getting cancelled irrespective of the risks involved. They can

challenge this score since it doesnt have any real world measures such as time and money.

Figure. 1 General process flow - Brainstorming & Evaluation

16

Structured brainstorming and evaluation can be coupled with Probabilistic Modelling to have

a mix of human experience and analytical expertise. The output of a quantitative risk model

enables us to understand a realistic range of expected outcomes and the risk of exceeding a

target set somewhere in that range. A sample output of a quantitative risk model can be

shown as

3.5 Technical Environment and Technical Details

Different companies have different parameters for judging the risk an IT project carries with

itself. Some of these are generally industry-wide excepted risks while some are project

specific. Along with these risks there are certain widely accepted risk reduction techniques

for each of them

RISKS RISK REDUCTION TECHNIQUES

Personnel shortfalls

Staffing with top talent, Job matching,

Teambuilding, Training and career

development, Early scheduling of key

personnel

Unrealistic time and cost estimates

Multiple estimation techniques, Design to

cost, Incremental development, Recording

and analysis of past projects, Standardization

of methods

Risk of

exceeding

target

Target Cost Realistically likely range of outcomes

Very risky targets

Unlikely to be achieved

Challenging targets

Might be achievable

Realistic targets

Likely to be achievable with

competent professional

management

Figure. 2 Sample output of a quantitative risk model

17

Developing the wrong software

Improved software evaluation, Formal

Specification methods, User surveys,

Prototyping, Early user manuals

Developing the wrong user interface Prototyping, Task Analysis, User

Involvement

Gold plating Requirements scrubbing, Prototyping, Design

to Cost

Late changes to requirements Change control, Incremental Development

Shortfalls in externally performed tasks Quality assurance procedures, competitive

design

Real time performance problems Simulation, prototyping, tuning

Development technically too difficult Technical analysis, Cost-benefit analysis,

Prototyping, Training Table 2 General Project Risks and Risk Reduction Techniques

When Project Managers of different organizations were interviewed about the cost and risk

estimates of their organization, they refused to disclose them citing confidentiality issues.

Hence following are some approximate numbers regarding the classification of project risks

and the classification of business impacts along with the costs associated them

.

PROBABILITY LEVEL RANGE

High Greater than 50% chance of happening

Significant 30-50% chance of happening

Moderate 10-29% chance of happening

Low Less than 10% chance of happening Table 3 Classification of Risks as per probability

Qualitative descriptors of impact on cost and associated range values are

IMPACT LEVEL RANGE

High Greater than 30% above budgeted expenditure

Significant 20-29% above budgeted expenditure

Moderate 10- 19% above budgeted expenditure

Low Within 10% of budgeted expenditure Table 4 Classification of Risks as per business impacts

3.6 Possible Applications in the Industry

The risk assessment methodology discussed here can be widely used across the IT industry

irrespective of the domain in which the project is applied. Structured brainstorming and

evaluation coupled with a Probabilistic Modelling is capable of giving experienced insights

as well as a systematic approach towards assessing risks associated with an IT project.

18

One such possible scenario in the industry where this methodology can be applied can be as

follows

During a project development there is often the problem of staff shortage when resources

leave. Normally multinational companies are well prepared to handle this situation by having

some bench strength. However, thats not the case with startups with low budget to afford

keeping resources on the bench, startups frequently face this issue of personnel shortfall. This

issue then quickly escalates into a barrage of problems such as wrong staffing. If

documentation is not maintained correctly, the next personnel taking over the helm of the

project might not get a clear understanding of the project goal thereby introducing

unnecessary features in the software thus encouraging goldplating. This then leads to

increased time, cost and hence overshooting the budget.

Having a structured brainstorming evaluation approach will help reduce this risk to a great

extent by bringing in a 360 degree view of the problem statement along with a rich and varied

experience of seasoned developers and programmers. But even in this case there is a chance

of human mistakes. To mitigate this risk, the Probability Modelling approach will help

develop a systematic approach to assess residual risks which often manifest in the least

probable situations.

CHAPTER FOUR

4.1 Findings

Companies handling IT projects have their own set of parameters which they feel are critical

to their businesses. Now some of these parameters are commonly accepted across the

industry while some are domain specific and when it comes to assessing the risks associated

with projects, it becomes essential to know these parameters. Without knowing the business

critical parameters, however best are the remaining factors necessary for a successful project,

the project is doomed for failure.

Some industry wide accepted parameters are

Time

Cost

Budget

Number of resources

Skilled resources

Other parameters [12] which come into play can be categorized as

19

Political Factors

Political factors are basically to what degree the government intervenes in the economy.

Specifically, political factors include areas such as tax policy, labor law, environmental law,

trade restrictions, tariffs, and political stability.

Economic Factors

Economic factors include economic growth, interest rates, exchange rates and the inflation

rate. These factors have major impacts on how businesses operate and make decisions.

Social Factors

Social factors include the cultural aspects and include health consciousness, population

growth rate, age distribution, career attitudes and emphasis on safety. Trends in social factors

affect the demand for a company's products and how that company operates.

Technological factors

Technological factors include technological aspects such as R&D activity, automation,

technology incentives and the rate of technological change.

Political

Economic

Social

Technological

Figure 3 PEST Analysis

20

The development of IT projects has been quite rapid in recent times thanks to the

tremendous improvement in the field of research and development. Projects have gone

global. The above enlisted factors directly and indirectly affect each other. Accordingly, risk

assessment methodologies differ from company to company a multinational global

corporation or a midsize company or a budding startup firm.

4.2 Recommendations

For all practical purposes, having a mix and match approach to assess risk is required. Hence

a structured brainstorming and evaluation technique coupled with a Probabilistic Modelling

approach is recommended.

4.3 Conclusion

In this research we have tried to identify the distinctive domain of IT project risk assessment.

We saw that risk assessment methodologies differ from company to company. There are

different factors which affect how an IT company adopt a risk assessment methodology. We

also critiqued different risk assessment methodologies generally accepted across the industry.

Before that we saw what are the risks generally associated with an IT project and how having

a mix and match approach to assess risks is beneficial to the organization.

We believe that IT project risk assessment deserves to be considered an independent field of

research but within the broader context of Project Management considering the dynamism in

the field of technology. As such, it has a continuous potential to inform and enhance the field

of IT Project Management, as it provides an excellent opportunity to challenge and rethink

central concepts and assumptions.

Assessing risks is one of the greatest challenges for project managers. The real problem may

not be the measurement per se, but how the measures may be used to come up with a unified

framework which can accommodate upcoming risks.

21

REFERENCES

[1] C. M. Harvett, A Study of uncertainty and risk management practice relative to

percieved project complexity.

[2] The Open Group, Technical Guide - Requirements for Risk Assessment, The Open

Group, 2009.

[3] J. Widman, ComputerWorld.com, October 2008. [Online]. Available:

http://www.computerworld.com/s/article/9116470/IT_s_big.

[4] S. G. M. Alter, Managing uncertainty in MIS, MIT Sloan Management, 1978.

[5] H. R. S. T. J. Barki, Towards an assessment of software development risk, Journal of

Management Information Systems, 1993.

[6] A. Gemmer, Risk management; moving beyond, IEEE Computer, 1997.

[7] P. K. J. O. S. Dey, Managing risk in software development projects: A case study,

Industrial Management and Data Systems, 2007.

[8] J. K. G. Jiang, Software development risks to project effectiveness, The Journal of

Systems and Software, 2000.

[9] D. P. Dorsey, Top 10 reasons why Systems Projects Fail.

[10] Wikipedia, Wikipedia.com, [Online]. Available: http://en.wikipedia.org/wiki/Fab.com.

[11] D. S. Gray, Project Risk Management Methods.

[12] Wikipedia.com, [Online]. Available: http://en.wikipedia.org/wiki/PEST_analysis.

Figure. 1 General process flow - Brainstorming & Evaluation

Figure. 2 Sample output of a quantitative risk model

Figure 3 PEST Analysis