Risk Assessment of Project

This article provides a detailed risk assessment of a project, including the scope of the project, risk measurement of the development and operational phase, project stakeholders, determination of risk acceptance, and proposed methodology to conduct the risk assessment.

Running head: RISK ASSESSMENT OF PROJECT
RISK ASSESSMENT OF PROJECT
Name of the Student
Name of the University
Author note

1
RISK ASSESSMENT OF PROJECT
Table of Contents
1. Scope of the project:.........................................................................................................................2
2. Risk measurement of the development and operational phase:.......................................................3
2.1. Development phase:...................................................................................................................3
2.2. Operational phase:.....................................................................................................................4
3. Project stakeholders:.........................................................................................................................5
3.1. Stakeholder involved in the project:...........................................................................................5
3.2. Perception of risk:.......................................................................................................................6
4. Determination of risk acceptance:...................................................................................................11
5. Proposed methodology to conduct the risk assessment:................................................................12
6. Project team involvement based on specializations/professions:...................................................14
7. Data collection method:..................................................................................................................15
8. Data validation:...............................................................................................................................19
9. Stakeholder communication plan:...................................................................................................19
10. Review and monitor program:.......................................................................................................20
Reference:...........................................................................................................................................22

2
RISK ASSESSMENT OF PROJECT
1. Scope of the project:
Title Timesheet Reporting Tool Date September 23, 2018
Project
Manager
Andrew Jason
Project
Justification
The tool is intended to provide a web based application that is user
friendly and provide the automatic means to track time entries that the
employee makes on daily basis
Project Scope
Description
To provide the option to tack and review time entries globally for the
Information Technology employees
Project
Objective
To felicitate all the Information Technology employees with the tool that
help them in tracking the timesheet entries for
High Level
Requirements
1. User access for the tool granted to all employees
2. provide the Admin access for support team
3. facility to Report the generation access to the project managers
4. help the users to have remote access to the tool
5. provide Standard templates for every reports
In Scope
1. Multi – level approvals made available for the timesheets
2. additions of Timesheet tasks to the tool through Admin approved
access users
3. ‘Copy Previous Week’ timesheets feature
4. Access tool for Desktop
Out of Scope
 1. addition of New project/task for the managers
2. HRMS connectivity for updating leaves taken by employee
3. and that too automatically
 4. template providing task list based on role
 5. facility of obtaining the Access tool via mobile and tablet

3
RISK ASSESSMENT OF PROJECT
Cost Estimate
Cost Item Estimated
Project Cost
Actual
Spend
Cost until
completio
n
Variance
Software $2300 $900 $1400 NA
Hardware $5000 $1500 $3500 +/- 1000
Other $750 $0 $750 +/- $100
Total $8050 $2400 $5650
Assumptions 1. users will update Timesheet on daily basis
2. task listed in the Timesheets will be updated twice a month
Deliverables
1. Single system to record time hours for FTE and Contractors
2. execution of the timesheet reports to for detecting entries that are not
present in the list
3. reports generation for the identification of the productive tasks along
with the work hours
4. charts generation for the steering committee packs
5. Detailed assistance for the user for updating tolls that belongs to all the
users
Constraints
 1. no facility to capture the leave from the leave system that are not
planned
 2. access for the timesheet view associated with the team is only available
to the Direct managers
2. Risk measurement of the development and operational phase:
In order to measure risk there should be proper framework and this varies according
to the scope and requirement of the project (Cleary, Horsfall and Hayter 2014).
2.1. Development phase:
Risk considered Impact of risk
Time frame High

4
RISK ASSESSMENT OF PROJECT
exceeds than the
estimated time
significantly
Cost exceeds
significantly
High
Requirement of the
system is not clear
to the developer
High
Code does not
integrate well with
the system
High
2.2. Operational phase:
System crashes and
the performance is
bellow acceptance
High
Security of the
system is not top
notch
High
The interface of the
system is not
attractive and
simple
Medium
System take more medium

5
RISK ASSESSMENT OF PROJECT
time to store and
process data
3. Project stakeholders:
The study of how each stakeholder involved in the project will perceive the risk is an
important factor, as without the study of stakeholder risk perception, it is not possible to
manage the project successfully as stakeholder engagement and stakeholder satisfaction one
of the key elements for project success. This is where analysis of stakeholder risk perception
becomes significantly important as without integrating each stakeholder perception about the
project risk, the overall risk of the project is not possible to identify and have proper control
over that. In the following section, the stakeholder for the project has been identified with
detailed risk perception of each of the stakeholder.
3.1. Stakeholder involved in the project:
Stakeholder Role
Project manager Monitor and control overall progress of the
project with control over the cost, timeline
approval and review on the project progress
Employee Only access to the feature approved by the
admin of the Timesheet Reporting Tool
Admin
Monitor and approve the user access to the
Timesheet Reporting Tool, hence responsible for
overall system security and performance
Developer Develop the code for the software

6
RISK ASSESSMENT OF PROJECT
Tester Review the code designed by the developer to
make the code integrated with the system and
platform
User interface design Design the interface for the software. The
interface is something through which the user
the
3.2. Perception of risk:
3.2.1. For the project manager
Once the stakeholder and the responsibility is defined it will help to define the risk
perception of the stakeholders. Only the project manager will have same view and risk
perception for the all the risk parameters described below as the project manager is
responsible for each and every aspect of the project progress and the associated risk (Brace
2018).
Project
manager
Risk considered Perceive of risk
Time frame
exceeds than
the estimated
time
significantly
High
Cost exceeds
significantly
High
Requirement of
the system is
High

7
RISK ASSESSMENT OF PROJECT
not clear to the
developer
Code does not
integrate well
with the system
High
System crashes
and the
performance is
bellow
acceptance
High
Security of the
system is not
top notch
High
The interface of
the system is
not attractive
and simple
High
System take
more time to
store and
process data
High

8
RISK ASSESSMENT OF PROJECT
3.2.2. Other stakeholder:
Apart from the project manger the other stakeholders will have different viewpoint on
the risks considered and they will perceive different risk aspect as high and low.
Stakeholder Risk(high ) Risk(low)
Employee None Time frame exceeds than
the estimated time
significantly
Cost exceeds significantly
Requirement of the system
is not clear to the developer
Code does not integrate well
with the system
System crashes and the
performance is bellow
acceptance
Security of the system is not
top notch
The interface of the system
is not attractive and simple
System take more time to
store and process data
Admin
Security of the system is not
top notch
Time frame exceeds than
the estimated time
significantly
Cost exceeds significantly
Requirement of the system

9
RISK ASSESSMENT OF PROJECT
is not clear to the developer
Code does not integrate well
with the system
System crashes and the
performance is bellow
acceptance
Security of the system is not
top notch
The interface of the system
is not attractive and simple
System take more time to
store and process data
Developer Time frame exceeds than
the estimated time
significantly
Requirement of the system
is not clear to the developer
Code does not integrate well
with the system
System crashes and the
performance is bellow
The interface of the system
is not attractive and simple
System take more time to
store and process data

10
RISK ASSESSMENT OF PROJECT
acceptance
Security of the system is not
top notch
Tester Code does not integrate well
with the system
System crashes and the
performance is bellow
acceptance
Time frame exceeds than
the estimated time
significantly
Cost exceeds significantly
Requirement of the system
is not clear to the developer
Security of the system is not
top notch
The interface of the system
is not attractive and simple
System take more time to
store and process data
User interface design The interface of the system Time frame exceeds than

11
RISK ASSESSMENT OF PROJECT
is not attractive and simple the estimated time
significantly
Cost exceeds significantly
Requirement of the system
is not clear to the developer
Code does not integrate well
with the system
System crashes and the
performance is bellow
acceptance
Security of the system is not
top notch
System take more time to
store and process data

12
RISK ASSESSMENT OF PROJECT
4. Determination of risk acceptance:
The risk acceptance of the stakeholders will directly base upon the way they perceive
the risk (Berghaus and Back 2014). Hence the measurement of the risk acceptance will be
same as for the risk perception. Hence which stakeholder will accept which risk and discard
other risk aspect will be measured with the reference to the risk acceptance matrix described
in the previous section. As for the example developer according to the risk acceptance matrix
is not concern about the interface of the software and data processing feature. Hence any risk
related to that will be accepted by the developer. However this risk aspect might not be
accepted by the interface designer as the risk perception of the interface designer against this
risk aspect is higher than other stakeholder involved in the project.
5. Proposed methodology to conduct the risk assessment:
In order to conduct risk assessment properly, it is important to identify and select a
proper risk assessment methodology (Tai, Huang and Chuang 2016). The risk assessment
methodology that will be followed in this project is the OCTAVE method. The method
include Operationally Critical Threat, Asset and Vulnerability Evaluation and hence the name
(Ehrenhard et al. 2014). It provides a structured approach for the evaluation of the operational
risk related to the project followed by the security best practices and the security tools that is
considered for the risk mitigation identified during the review and monitoring of the project,
both in the development and the operational phase of the project (Legner, Urbach and Nolte
2016). After evaluating the stakeholder risk perception and impact on the overall project the
following risk assessment matrix will be developed that will consider a set of attributes. This
attributes as well as the matrix will be considered as the reference for the risk assessment.
The matrix is provided bellow :

13
RISK ASSESSMENT OF PROJECT
Attribute Low Risk
(0-4% Growth)
Moderate Risk (6-
10% Growth)
High risk
(12- 15 % Growth)
Maturity Software is
operational as per the
requirement and the
objective of the
development
The software
development is
complete , but in the
pilot phase and there
is need for
architectural
adoption
The development is not
completed , requires pilot
test as well as there is
need to adopt the
architectural framework
Perfonnance Performs as the per
the need of the
interface
requirements and
there is no difference
Slight difference in
the performance and
the interface
requirement
Significant difference in
the performance and the
interface requirement
Integration
complexity
Simple to integrate
with the system or
the platform
Not so Simple to
integrate with the
system or the
platform, yet not that
complex
Significantly complex to
integrate
Quality Proper quality
maintained in the
software
development
Quality not properly
fulfilled yet
acceptable
Quality not maintained at
all and not at all
acceptable and there is lot
of defects in the system
Control Offers total control
over the system
System is sometime
difficult to control ,
System is extremely
difficult to control

14
RISK ASSESSMENT OF PROJECT
parameters such as
security and
administration of the
system
but that is not very
often
Access Both the high and
low level access is
secured and works as
expected. High level
access includes
administrative access
and low level access
includes user access
to the system. both
level of access is
secured and accurate
as per the
authorization
Some issues with the
low level access,
however there is no
issues with the high
level access
Both the high and low
level access is not secured
and does not works as
expected
familiarity The user as well as
the system admin has
full familiarity with
the system
The user as well as
the system admin has
some level of
familiarity with the
system
The user as well as the
system admin has no
familiarity with the system
Property Rights &
licenses
property right and
licenses are
adequately acquired
property right and
licenses have issues,
but not known
property right and licenses
are not adequately
acquired

15
RISK ASSESSMENT OF PROJECT
6. Project team involvement based on specializations/professions:
specialization time of involvement Reason for involvement
Project manager At the beginning of the project To decide project variables
including cost, time frame and
scope
Developer At the start of software design To design the code for the
software
Tester After the design of code
completed
To test the compatibility of the
code for the system and
platform for the software
design
Interface design After the testing is done for the
software
To design the user interface for
defining the procedure for
interacting with the system
7. Data collection method:
Data collection is an important step for the project. Without proper data collection it is
not possible to set the correct project deliverable and without proper project deliverable it is
not possible to lead a project with success. The data collection will be conducted in the
following way :
Type of data Stakeholder Description of
data
Time frame Data collection
method
Quantitative Project manger The project
manager will be
7-10 days Meeting will be
arranged with the

16
RISK ASSESSMENT OF PROJECT
involved in the
data collection
method for
collecting
information such
as cost , required
time for project
completion and
project approval
manager in probably
2 or 3 session. One
session will be
direct on the
premises meeting,
while other session
will be arranged
through Skype or
video call. Data will
be recorded in the
excel sheet.
Qualitative Administrator The administrator
will be
responsible to
provide
information such
as level of
security need ,
number of people
who will have
access to the
system admin
facility and
number of users
who need to be
3-4 days One direct meeting
will be arranged in
the office and other
meetings will be
conducted through
the video conference
and direct email
conversion
whenever needed.
Excel sheet will be
used for recording
of the data

17
RISK ASSESSMENT OF PROJECT
integrated to the
system
Qualitative Developer The developer
will be
responsible for
providing
information on
the best
technology to be
used and best
procedure to
follow to
complete the
project within the
estimated time
allocated for the
project
5-7 days Direct meetings
whenever needed
along with email
and video chat
Qualitative Tester The tester will be
involved to
collect
information such
as how the
system is
performing , bug
in the system and
5-7 days Direct meetings
whenever needed
along with email
and video chat.in
order to record the
data excel sheet will
be considered

18
RISK ASSESSMENT OF PROJECT
any improvement
in the code if
needed
Qualitative User interface
designer
Information like
what are best
technology for
design of the user
interface for the
application ,
estimated time
for the design and
design constraints
and best
technology within
the budget will be
collected from
the user interface
designer
4-7 days Direct meetings
whenever needed
along with email
and video chat. data
will be recorded in
the excel sheet
Qualitative employee The employee
will be
responsible to
provide feedback
for system after
they have used.
Information
2-3 days Online as well as
offline survey.
However the survey
data will be
recorded in the
excel sheet.

19
RISK ASSESSMENT OF PROJECT
related to system
look and design,
ease of use and
effectiveness of
the system will be
collected from
the employee as
they are the end
user of the system
8. Data validation:
The data that is collected through the meeting and stored in the excel sheet will be
validated with the help of regression analysis which is statistical model for data validation.
Here the numerical results quantifies relationships between variables that is hypothesized.
Then the result of quantification is measured with respect to the fact whether the result is
acceptable as described in the dataset itself (Lyberopoulos et al. 2016).
9. Stakeholder communication plan:
Delivera
ble
Recipie
nt(s)
Delivery
Method(s)
Schedul
e
Who's
R
Project
Information
Project Team SharePoint
Team meetings
Conference calls
As needed Project
manager
Proj ect
Status
Proj ect Planner
Project Director
e-Portfolio
Email
Weekly Project
Manager
Agenda
minutes
Project Team
Steering committee
Email
SharePoint
Team meetings
Monthly Project
Manager

20
RISK ASSESSMENT OF PROJECT
Timeline
Update
Steering
c o m m i t t e e
Meetings
SharePoint
As needed Project
Manager
Project
Updates
Action
Project Manager Team meetings
Email
Conference calls
As needed Project
Team
Project Risks ITEC/Exec.
Sponsor
Project Steering
committee or
Steering
committee
Project Team
Risk Document
Meeting minutes
As needed Project
Manager
10. Review and monitor program:
RISK IDENTIFICATION RISK MONITORING & REVIEW
Event Method What will be reviewed Status
Software is working properly
Monthly review at
Practitioner/Partner meeting
Documentation review
status to identify whether it is
complete accurate and proper
OPEN
Security of the software is
intact
Weekly review at developer
and system admin meeting
Security vulnerability report
documentation and the
corresponding techniques for
OPEN

21
RISK ASSESSMENT OF PROJECT
security
Data is collected as per the law Monthly review at the
manager and HRM
department meeting
To review and check the
compliance of data collection
procedure
OPEN
Software is updated
Quarterly review of
succession plan
1. to identify whether proper
update is rolled out to the
software or not
2. if update is rolled out
properly what is the
procedure followed and what
resources are considered
OPEN

22
RISK ASSESSMENT OF PROJECT
Reference:
Berghaus, S. and Back, A., 2014. Analysis of project risk and its Impact on Organizational
Stakeholders.
Brace, I., 2018. Questionnaire design: How to plan, structure and collect project data. Kogan
Page Publishers.
Cleary, M., Horsfall, J. and Hayter, M., 2014. Data collection and validation in project: does
size matter?. Journal of advanced nursing, 70(3), pp.473-475.
Ehrenhard, M., Wijnhoven, F., van den Broek, T. and Stagno, M.Z., 2017. Unlocking how
manager create business value with risk assessment : Development of an App-enabled
Business Innovation Cycle. Technological forecasting and social change, 115, pp.26-36.
Legner, C., Urbach, N. and Nolte, C., 2016. Stakeholder communication for service and
maintenance processes: Using ex post evaluation by end-users as input for iterative design.
Information & Management, 53(6), pp.817-831.
Lyberopoulos, G., Theodoropoulou, H., Filis, K. and Mesogiti, I., 2016. Smart Mobile
Ecosystem Security for software project: Existing Solutions, MNO Requirements and
Business Model. In project management and control 2015 (pp. 137-146). Springer, Cham.
Tai, Y.T., Huang, C.H. and Chuang, S.C., 2016. The construction of a successful
project. Kybernetes, 45(1), pp.141-157.
Winter, J., Battisti, S., Burström, T. and Luukkainen, S., 2018. Exploring the success factors
of effective project management. International Journal of Innovation and Technology
Management, 15(03), p.1850026.