Anda di halaman 1dari 21

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)

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.

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

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.

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.

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
-

1.5

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

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.

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.

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 wellestablished IT multinational player how these companies have different approaches for risk
assessment.

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.

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

10

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.

11

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
Informal
direct
assessment of risks

Checklists

Risk indicator series

Identification
and
prioritization of risks
risk 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
Works well if the latest job
goes no further than the
material used to develop the
list
Works as a support for
subjective judgement when
the content and commercial
environment of your project
is routine and scales have

Budget,
target
and
contingency settings
Rating depending on the
judgement

No direct value except in


providing input to subjective
judgement
Misused by inexperienced
personnel trying to convert
the scales into direct value

12

been calibrated
Structured and brainstorming Depends on the team
evaluation
members for brainstorming
More effective than a single
person team
Probability

Impact No direct help in identifying


Calculations
risks

Probabilistic modelling

Can be used as a framework


for risk identification and
tends to highlight any gaps in
plans
and
optimistic
assumptions

Has the capacity to develop a


360 degree view thus
ensuring
a
good
understanding of the solution
Suffers with problems of
characterizing
risks
for
uncertain events with single
probability, false sense of
security
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

13

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

14

o Rank and prioritize the risks


Treat the risks
o Identify options
o Select the best responses
o Develop risk treatment plans
o Implement

Figure. 1 General process flow - Brainstorming & Evaluation

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.

15

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

Risk of
exceeding
target

Very risky targets


Unlikely to be achieved

Challenging targets
Might be achievable

Realistic targets
Likely to be achievable with
competent professional
management

Realistically likely range of outcomes

Target Cost

Figure. 2 Sample output of a quantitative risk model

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

Personnel shortfalls

Unrealistic time and cost estimates

RISK REDUCTION TECHNIQUES

Staffing with top talent, Job matching,


Teambuilding, Training and career
development, Early scheduling of key
personnel
Multiple estimation techniques, Design to
cost, Incremental development, Recording
and analysis of past projects, Standardization
of methods

16

Developing the wrong software


Developing the wrong user interface
Gold plating
Late changes to requirements
Shortfalls in externally performed tasks
Real time performance problems
Development technically too difficult

Improved software evaluation, Formal


Specification methods, User surveys,
Prototyping, Early user manuals
Prototyping, Task Analysis, User
Involvement
Requirements scrubbing, Prototyping, Design
to Cost
Change control, Incremental Development
Quality assurance procedures, competitive
design
Simulation, prototyping, tuning
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

High
Significant
Moderate
Low

RANGE

Greater than 50% chance of happening


30-50% chance of happening
10-29% chance of happening
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
High
Significant
Moderate
Low

RANGE
Greater than 30% above budgeted expenditure
20-29% above budgeted expenditure
10- 19% above budgeted expenditure
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.

17

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

18

Political

Technological

Economic

Social

Figure 3 PEST Analysis

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.

19

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.

20

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

21