Post on 04-Mar-2023
RISC- Risk Identification Status and Control
By
Andrew Packard
A senior research paper submitted in partial fulfillment of the requirements for the degree of
Bachelor of Science in the Department of Mathematics and Computer Science in the College of
Arts and Science at Stetson University
DeLand, Florida
Spring Term 2009
2 | P a g e
Table of Contents
1. Introduction....................................................…..................................................................................... 3
2. Project Management..............................................................................................................................4
3. Risk Management.................................................................................................................................. 5
3a. Quantifying Risk....................................................................................................................... 6
3b. Network diagrams and Estimating Risk................................................................................... 8
3c. Critical Path Method................................................................................................................ 10
3d. Program Evaluation Review Technique................................................................................... 12
3e. Prioritizing and Exposing Risk.................................................................................................. 16
4. RISC - Introduction................................................................................................................................. 18
5. RISC – Goals, Prerequisites, and Issues…............................................................................................... 20
6. RISC – Design and Development…......................................................................................................... 21
6a. Requirements – System Abilities………………………………………………………………………………………….. 22
6b. Requirements – Database Design and Implementation……………………………………………………….. 25
6c. Requirements – Layout Design...……………………………………………………………………………………….... 28
6d. Requirements – PHP and MySQL…..…………………………………………………………………………………….. 29
6e. Requirements – Symfony…………………………………………………………………………………………………….. 29
7. RISC – Modules and Functionality….......................................................................................................31
7a. Risc Module – Users………………………………………………………………….…………………………………………. 32
7b. Risc Module – Portfolio…...……………………………………………………………………………….…………………. 33
7c. Risc Module – Project…......…………………………………………………………………………………………….……. 34
7d. Risc Module – Task…….....……………………………………………………………………………………………………. 34
7e. Risc Module – Risk……......……………………………………………………………………………………………………. 36
7f. Risc Module – Notification…..……………………………………………………………………………………………….. 35
8. Conclusions…………………………................................................................................................................. 36
9. Future Possibilities……………………........................................................................................................... 36
10. References……………...…………….............................................................................................................. 38
3 | P a g e
Abstract
With rising concerns in project management due to economic conditions and job security, more
companies are looking at proper risk management to safeguard their assets and capitalize on
opportunities. Modern project management in the United States started in the 1950s with two
breakthrough techniques for planning and scheduling, the “critical path method” or CPM, and
the Program Evaluation and Review Technique or PERT. Both techniques are mathematical
tools for estimating uncertainty in task duration and cost, however, neither technique handles
tracking risks that potentially threaten the overall cost, or critical path of any project or
portfolio of projects. The purpose of this research is to implement a unique project
management software package that assists the user in tracking and controlling risk. This is done
not only for a single project, but for an entire portfolio of projects.
1. Introduction
All projects are subject to risk of some kind, and in order to be successful, risk must be
identified, monitored, and controlled. Much like the housing markets crash in mid 2008,
assuming unacceptable risk is detrimental to business and can cause bankruptcy [1]. For this
paper a web application was developed using with the advice of several project managers to
help illuminate the risks of each task in a project. This system was further designed to hold risk
data for an entire portfolio, or many projects, and provide an overall risk exposure. Tracking
risks and exposing them to all levels of management is the main priority of the developed
software based on probabilities and critical paths. This allows the project and portfolio
4 | P a g e
managers to take proactive measures to protect the quality, scope, cost, and schedule of their
project(s) or accept the indentified risk.
2. Project Management
Project management may be defined as “an endeavor to accomplish a specific objective
through a unique set of interrelated tasks and the effective utilization of resources” [5]. A
project must have the following parts:
Objective – normally defined as cost, schedule, and scope. The cost is the total amount of
money required to complete the objective. The schedule is the time frame the objective will
take. The scope is the quality and customer satisfaction.
Interdependent tasks – non-repetitive tasks that are finished in a sequence to achieve the final
objective. A task may have multiple predecessors to be completed before that task may start.
Resources – this includes people, organizations, equipment, and facilities.
Degree of uncertainty – the objective and related tasks are prepared based on a set of
assumptions and estimates. Any threat to these assumptions, whether known or unknown, is a
risk. Herein lies the issue. By not protecting or checking the assumptions and documenting
uncertainty properly a project may be doomed to failure. One of the focuses of the designed
software is to help management influence controllable parts of uncertainty.
5 | P a g e
Figure 1: An example of how larger organizations operate on portfolio and project levels [7].
Figure © PMBOK 4th Edition.
3. Risk Management
There are several ways companies focus on, or ignore the influence and control of
uncertainty. Incorporating the concepts and mathematical theories behind risk management
can help mitigate and illuminate risk potentials in a project. Any given task has several factors
to consider when applying risk management [4]:
• Specific factors that impact scope, time, cost, and quality
• Quantify the likelihood of each known impact
• Mitigate/Avoid/Transfer impacts by influencing controllables
Scope is broken into categories of total certainty and total uncertainty: unknown unknowns,
known unknowns, and knowns [2]. Uncertainty is the root cause of risk management study. For
instance, when considering uncertainty as a set of unknowns the outcomes can be favorable
(opportunity) or unfavorable (risk). The goal of risk management is to influence controllable
knowns from unfavorable risks to favorable opportunities in a proactive way [3]. Project risk is
defined as: “the cumulative effect of the chances of uncertain occurrences adversely affecting
project objectives” [4].
With those definitions in mind the earlier risk is assessed the less the impact on the overall
project. To ignore potential risks or make changes later in a project is known as the Godzilla
Principle [5]: When a problem is caught at the planning stages with little to no allocation of
6 | P a g e
resources, the potential problem, or monster, has not yet grown into a full scale behemoth to
be reckoned with. The moral: catch the problems early, and be proactive rather than reactive.
3a. Quantifying Risk
Risk is quantified by the following model, called risk exposure [6]:
Risk Exposure = Risk Probability X Amount at Stake
This model estimates the risk exposure as cost in dollars. Since time generally equates to
money through usage of resources, only cost is widely used. It is up to the company to decide
when and how to quantify the risk exposure. For instance, a low probability but high stake risk
might have the same exposure as a high probability, low stake risk. This is known as a risk
matrix. The risk matrix is a standard of process assets that suggest what actions should be
taken. Interpreting the risk exposure and making the best possible choice is very important to
understanding the result provided by quantifying risk. Earlier it was stated that a project has a
series of interdependent tasks. This means that more than one task probability can be
calculated and must be considered. What if there are two events that are required to be
completed before moving to the next task? Then the likelihood of both must be calculated.
Consider this example conversation between a project manager and program manager:
Program Manager: “What is the probability of getting our software requirements defined and
project approved? This must be done before we can start designing.”
Pr(Requirements) x Pr(Approval) = Pr(Both Events)
7 | P a g e
Project Manager: “The probability looks rather promising, around 80% we’ll have the
requirements done, and 70% we’ll get approval.”
Both events are possible but not completely certain so both must be calculated because both
are required before planning can begin:
0.80 x 0.70 = 0.56 = 56% likely chance for planning.
In this example there is slightly better than a 50-50 chance that the project will move to the
planning stage. If the program manager accepted the word of the project manager blindly, he
or she would have approved a task with a 56% chance of success. However, what if only one is
required to move to planning, the probability is as follows:
Pr(No Requirements) x Pr(No Approval)
0.30 x 0.20 = 0.06 = 6% chance that neither will happen
Obviously 94% chance to move to planning is much better than a 56%. However
interdependencies of tasks dictate the success and cost of the entire project. This is why risk
interdependencies must be monitored and action must be taken to increase the probability of
success.
To properly schedule a project, the risks and probabilities must be accounted for. This is done
by a network diagram.
3b. Network Diagrams and Estimating Risk
8 | P a g e
When diagramming an entire project’s tasks it is important to keep three measures
exposed: cost, time, and probability. In the previous section on Quantifying Risk, there was an
example of a project that needed approval and requirements. In this example, the project is
expanded into five tasks:
A. Goals Defined
B. Requirements Defined
C. Project Approval
D. Project Design
E. Development
Figure 2 shows an “in-the-box” network diagram of all interrelated tasks and the cost of each.
Figure 2: Example Network Diagram with cost estimates
From figure 2 there are two possible paths of interdependency:
9 | P a g e
1) A-B-D-E – Path Cost: $8,200
2) A-C-D-E – Path Cost: $19,700
Total Project Cost (All Tasks): $20,200
It is important to note that the paths are not a choice. All tasks must be completed; however, in
the order of completion is now diagramed. Explained further:
1) Task A is completed first. This must be completed before B, C, D, and E and be started.
2) Once Task A is completed, B and C can be started at the same time; however both must
be completed before D can be started.
3) Once B and C are completed, D can be started.
4) Once D is completed, E can be started
5) Once E is completed the project is completed.
Task D has a two part dependency and this has interesting properties when applied to the
Critical Path Method.
3c. Critical Path Method
Also known as the critical path analysis, this effective tool is used to show the duration for each
interrelated task, and the total duration [4]. Previously two paths were mentioned: A-B-D-E and
A-C-D-E. In figure 2, the same network diagram has been modified to include task durations.
10 | P a g e
Figure 2: Example Network Diagram with duration estimates
In figure 2, A-B-D-E has the total duration of 13 days and A-C-D-E has the duration of 15 days.
The critical path is the longest duration. Therefore, the critical path is A-C-D-E, meaning no
matter how many other paths a project has, the total duration of the project will also be the
duration of the critical path [7]. This is diagramed in figure 3.
11 | P a g e
Figure 3: Example Network Diagram with critical path shaded in red.
The critical path is used for prioritizing tasks based on the CPM results. These results are useful
for “crashing” the path. “Crashing” the path means to shorten tasks along the critical path to
shorten the total project duration and complete the project faster [8]. If the critical path is
shortened so that any other path has a longer duration, that path will become the new critical
path. To apply the CPM to risk management, the most risky path can be determined, as shown
in figure 4.
12 | P a g e
Figure 4: Example Network Diagram with most risky path shaded in red
With figures 1, 2, 3, and 4 referenced together, a picture can be painted about what kind of
project has been diagramed. A-C-D-E has the highest cost, longest duration, and is the most
risky. Proper risk management suggests that this path and all tasks along the path be monitored
carefully and mitigated properly [2] [3] [5] [7].
3d. Program Evaluation Review Technique (PERT)
Much like the CPM, a PERT chart is a way of representing activities plotted against time. Where
the CPM is weak, the PERT chart has its strength, and that is activity duration estimates. The
CPM has a very rigid structure in that should any task not be done on time, the critical path is
severely affected. The PERT solves this problem by understanding durations as estimates of
optimistic (o), pessimistic (p), and most likely time (m) [4]. This is represented by a beta
distribution estimation using a 1-4-1 weighted average[4] [7]:
13 | P a g e
Expected Time t(e) = ������
�
Optimistic time estimate (o) – the estimate that assumes all tasks will go as planned or better.
Most likely time estimate (m) – the estimate which would occur most often. This is not the
same as “expected time”, which is the eventual outcome of the PERT.
Pessimistic time estimate (p) – the estimate that assumes the most adverse conditions, but not
major disasters or extraordinary circumstances.
As shown in figure 5, the PERT expected times have been added to the previously used project
example.
Figure 5: Example Network Diagram with PERT analysis and critical path marked in red. The
PERT is marked as o-m-p / t(e) (Expected value calculated)
14 | P a g e
The total expected completion for the project is 19.32 days. With that there is currently a 50%
chance of completing the project before that, and 50% chance of completing after that. For
most project managers this simply is not good enough. The variance in the project completion
time can be calculated by summing the variances on the critical path. This requires the usage of
standard deviation for each task [4] [7]:
Standard Deviation = �����
Figure 6: Example Network Diagram with PERT calculations and standard deviation (o-m-p /
t(e) / σ)
The variance of the critical path must be calculated [4] [7]:
�� ����� � ���� ��
15 | P a g e
For this example this comes out to be A(1.7689) + C(9.9856) + D(0.4356) + E(2.25), which is
14.4401. Next the standard deviation for the total project is calculated [4] [7]:
���
The standard deviation for this project is 3.80 days. With our PERT prediction of 19.32 days, the
estimation is -/+ 3.80 days. Using 1σ (3.80) standard deviation over, there is a 15.52 – 23.12
range of days. Using this range a Z table can be used to calculate the probability this range will
occur using the following formula [4] [7]:
� ����������� � �!"#�$������%
Using the current example the Z value would be 2 and the probability of occurrence would be
97.7% accurate. It is clear that mixing the PERT with CPM can give an accurate representation
of the critical path times. Applying risk management to the assumptions made, one can protect
and safeguard the 97.7% prediction.
As seen, PERT and CPM have nothing to do with risk monitoring and control, except
allowing one to apply predicted estimations of best and worst times. This leaves a rather large
hole in the monitoring and control aspect of risk management. Project and Program managers
need a quick and effective way of prioritizing risk.
16 | P a g e
3e. Prioritizing and Exposing Risk
To effectively monitor and control risks, a rating is given to estimate several potentials,
such as: resources, quality, contingency plans, and mitigation strategies. This paper will discuss
three strategies for prioritizing risk that are common among project managers: [22][28] risk
exposure, categorical approach, and quantified categorical approach.
The first method is called expected value technique. This is calculated by multiplying the
risk’s probability of occurrence by the potential loss.
&' (!�)�)�"��#�&�����
The result is the risk’s expected value of estimated loss. This value can be ranked from highest
to lowest with the highest expected values top priority.
The second method is the categorical approach. As stated in the proposal, a risk matrix
is used to qualitatively expose risk. Qualitative measurements are much more subject to
interpretation, but allow for a risk to be measured when its probabilities or loss measurements
cannot be accurately assessed. Below is an example risk matrix.
Probability
Impact
Low Medium High
High High + Low High + Medium High + High
Medium Medium + Low Medium + Medium Medium + High
Low Low + Low Low + Medium Low + High
17 | P a g e
Both approaches have their strengths and weaknesses based on how the estimations are made.
Prioritizing risk is to help the management improve the realism of their designed schedule and
goal. Not all risks need to be mitigated and each company will define their risk tolerance
differently. The risk tolerance is a threshold that when surpassed a risk is considered
unacceptable and the appropriate action of mitigate, avoid, transfer to lower damage is
generally taken [4] [11]. Risk exposure is considered one of the best ways of prioritizing risk for
businesses because the expected value is monetary. However, if the accuracy of the probability
or impact are low and the result is not believable, undetermined, or is not determinable then
risk exposure cannot be used. Categorical approaches (qualitative measurements) are a good
secondary prioritization tool when a quantitative result is not determined or if the project is
small. In larger projects where many managers are prioritizing at the same time, more likely
than not their lists will be different because of the subjectivity of categories.
To help solve this dilemma and give a more quantitative approach that can be used in
risk software a hybrid has been made called PERIL [28]. PERIL essentially uses a beta
distribution with an interval between [0,1] to determine quantitative values for categories. The
beta distribution is taken one step further using a method called Ranked Order Centroids or
ROCs [29]. ROCs are ranked categories normalized so they add up to one. Expressed in sigma
notation for N values the kth ROC value is [29]:
*+,�-.
/012 34
18 | P a g e
For two categories the results are:
High I1 = (1 + 1/2) / 2 = 0.75000
Low I2 = (0 + 1/2) / 2 = 0.25000
It is important to note that when using PERIL the terms likelihood and impact are used over
probability and loss because they are not direct quantitative estimates. From the two category
example one can assume the probability of “High” is greater than 0.5 and “Low” has a
probability less than 0.5. Since categories are a form of rate data, for example, four categories
are ranked 1st/4, 2nd/4, 3rd/4, and 4th/4, a harmonic technique (order relation) is used. There are
several strengths to using PERIL to prioritize risk over a strict categorical approach. The first
strength is that PERIL is very computationally friendly. This makes creating a generic approach
for risk monitoring software possible when the user has incomplete data (No accurate
probability or loss estimate). The second strength is how the categories are ranked to limit
subjective interpretation. The quantitative ranks allow the user to set their risk tolerance and
be notified when any task is flagged. This helps software like RISC have a more accurate
methodology behind risk prioritization. Research suggests that ROCs are both a high accuracy
and effort technique, while not as effective as quantitative ratio weights (such as expected
value), are better than rank-sum weights and equal weight methods [30].
4. RISC – Introduction
RISC is a web application that can be used to help both project managers and upper
management list and visualize estimated risk and mitigation strategies for both a project and an
19 | P a g e
entire portfolio of projects. As mentioned previously, the goal is to lower the uncertainty and
influence controllables. RISC is a communication tool that expresses risks as a quantified
variable given at the project manager level. It allows the program manager to see the risks, or
known unknowns and how the project manager quantified them, and take action if needed. In
interviews with Jeff Haught and Gregory Packard [11], their twenty years in the aerospace
industry suggests that poor communication between upper management and the project
managers results in several problems. When the upper management is blind to the risks of their
projects because of misrepresentation or poor communication the project can be in danger of
failing and a risk trigger activates with no intervention. RISC is designed to keep all involved
parties in contact to prevent catastrophic risk triggers and lower negative impact.
Once the risks are quantified and their certainties measured, the next step is monitoring
and control. As stated previously, a risk is an unknown with an impact that negatively affects
the task and the project depending on the interdependency. At the project level, a project
manager needs to protect the assumptions (project schedule and cost) by mitigating, avoiding,
or transferring risk to improve probability of a more favorable outcome. At the portfolio level, it
is important to hide the complexity of project within a portfolio and concentrate on the overall
exposure and potential loss for the entire portfolio [22]. To do this, RISC uses a layout system
that allows one to “drill down” through the layers of detail. This will be described later in RISC –
Frontend Design.
The remainder of this paper explains the process in which RISC was created and how it is useful
in project management, more specifically, risk management.
20 | P a g e
5. RISC – Goals, Prerequisites, and Issues
When starting a large scale project several issues have to be addressed and several
questions have to be answered. Before any coding or even designing, a goal was established to
give a clear directive of what kind of software was to be developed and what kind of users will
be utilizing the application. To create software for project management the follow issues had to
be addressed:
1. One must understand the target audience (Project Managers, Portfolio Managers, Risk
Managers)
2. One must understand the target subject (Project Management, Risk Management)
3. One must gather requirements and get approval from my advisor and target audience
4. A backend and frontend design must be created that meets the requirements to support
the target audience and subject. Both designs have to be approved.
5. Since the application is a web application, a server with appropriate software must be
setup
6. A framework must be developed or an existing one is used to uniform code and
functionality. The framework must adhere to standards and the API must be learned.
Each issue is answered is greater detail in the remaining sections, but here is a brief
overview of each issue was handled:
1. The target audience was interviewed either in person, or over the phone. Several
project managers gave their input from different fields and companies about how
project management was done.
21 | P a g e
2. The target subject was studied from the PMBOK (Project Management Body of
Knowledge) standards according to the Project Management Institute.
3. An IEEE standard list of requirements was created stating each system and application
requirements.
4. An entity relation diagram was developed for the backend, and for the frontend use
case diagrams were created to understand application flow.
5. A development server was set up with Apache, PHP, MySQL installed.
6. Symfony, discussed in section 6e, was chosen as the framework for RISC, which meant
that its helper classes and semantics had to be learned.
6. RISC – Design and Development
This section discusses the design and development of RISC as a web application. This
includes requirements, database modeling, website design (PHP and HTML), functionality and
implementation. The main goal of RISC was to be a tailorable, generic, and useful risk
management tool. The software was not designed around any specific business, and may be
edited to fit the needs of a particular industry that uses or is willing to use Project Management
Institute standards and has access to web based applications. To determine requirements,
interviews with experienced project managers such as Jeffrey Haught, Gregory Packard, and
Gary Oliphant were used as a basis for understanding the target audience. This helped
determine the look and feel for the application and what kind of data was relevant to the
potential users. Also understanding the subject matter was very important for ease of
communication between the developer and the users (project managers). By studying risk
22 | P a g e
management and the PMBOK, a better understanding of the needs of the audience and the
requirements for RISC were more refined.
6a. Requirements – System Abilities
The project was split into three iterations for development and implementation (for a complete
list of requirements see the Appendix):
Iteration 1 (Bold denotes primary requirement): Project Construction
A. Secure Login System with SHA password encryption
a. Password retrieval or change
B. Users Management System
a. Create, edit, delete users
i. User account privileges (Admin, Project Manager, Program Manager)
b. Assign Projects to a Project Manager
i. Design Decision: Only one project manager per project
C. Project Manager Risk Register
a. Project
i. Creation, edit, and deletion
ii. Assigned a Project Manager
iii. A project manager may have many projects
b. Critical Path and PERT
i. Tasks are sorted by Critical path and Most risky Path
ii. Total Project Cost shown
23 | P a g e
iii. Project Completion probability shown
iv. Total Cost Loss Potential shown
Iteration 2: Portfolio Construction
A. New User
a. The Program Manager
i. May have one or more assigned portfolios
ii. May view any project within their portfolio
B. Portfolio
a. Design Decision: may have one or more assigned program managers
b. By Definition: has one or more projects
c. Shows Risk Exposure (Total Potential Loss as $)
d. Rates Risk Exposure based on desired threshold
i. Thresholds are decided by the user (i.e: Show all projects with risk
exposure above $100,000 as High, $50,000 as Medium, etc)
C. Notification System
a. Notifications are given to program managers when a task’s risk changes from
high to low, low to high, or if a high risk task is removed or added
Iteration 3: Archive System
A. Projects
a. Once a project is completed it becomes archived into a separate database
i. Holds the same fields
24 | P a g e
ii. All tasks must have their outcomes stated
iii. All loss is recorded
iv. Scope, Time, And Cost ratings are given for the completed project
B. Portfolios
a. Design Decision: These are not archived. Projects know what portfolio(s) they
were in
C. Search
a. The archive may be searched by project attributes (title, dates, portfolio) or
task attributes (name, description, risk)
b. No further edits can be made for an archived project
i. Except by Admin
As noted above, there are three subjective design decisions made (I1.B.b.i , I2.B.a, and I3.B.a).
The first lies in Iteration 1: “Only one project manager per project”. The assumption is made
that most projects will only have one risk officer or project manager that directly reports to
upper level management [11]. This avoids update issues with more than one manager trying to
edit and calculate project risks and potentially overwriting the edits of another. This
requirement can easily be changed in the database to reflect a many-to-many relationship
between project and project manager. The second assumption that many portfolio managers
(upper level managers) are monitoring many portfolios at once, and more than one may be
viewing the same portfolio [12]. The third assumption is that portfolios will not be archived.
Essentially a portfolio may never end, and its basic purpose is to group projects together for
total cost, and show the individuals responsible for the completion and approval of the project.
25 | P a g e
These fields are easily stored in the archive tables of the database, and do not need to be
repeated [10].
6b. Database Design and Implementation
For a relational database to run, operate efficiently, and be easily maintained it must be
designed properly. To alleviate problems, such as update anomalies, in a relational database
the process of normalization is used. Essentially, normalization is a formal checking system with
a list of rules that structures relational databases developed by E.F. Codd in 1970 [10] and is
considered one of the best and most widely used methods for handling relational databases.
Normalization has several levels called Normal Forms. Each normal form has a set of rules that
logically separate data to limit redundancy, avoid update problems, and control dependency
[9]. RISC’s database was normalized through third normal form, which is considered adequate
to handle most relationship databases, even though there exist higher normal forms.
(1NF) First Normal Form – A very simple form, stating all pieces of data are to be in separate
fields. Any table with fields that hold multiple values is not in 1NF.
1NF Example:
empID firstName lastName Email phoneNum projID projName projDesc projCost
1 Andrew Packard Email 555-543-123 4 Project 1 A Project $100
2 Daniel Plante Email 555-213-123 2 Project 2 Another one $500
26 | P a g e
(2NF) Second Normal Form – Includes the rules from 1NF, and all fields in the key to determine
the values of non-key fields. To make a table in 2NF, it must first comply with 1NF and remove
non-key fields that are not determined by the primary key. A separate table is made and those
values are now determined by a new primary key. This occurs until the only data within the
table is completely dependent on the primary key. The 2NF example below shows how the 1NF
example can be made to conform to 2NF.
2NF Example:
Employee_Table
empID firstName lastName Email phoneNum
1 Andrew Packard Email 555-543-123
2 Daniel Plante Email 555-213-123
Project_Table
projID projName projDesc projCost Portfolio Portfolio_Name
1 Project 1 A Project $100 1 Portfolio 1
2 Project 2 Another one $500 1 Portfolio 1
(3NF) Third Normal Form – Includes the rules from 2NF, and no non-key fields depend on fields
that is not the primary key. To make a table 3NF compliant all non-key fields that are
dependent on a field or fields that is not the primary key are removed and placed into a
separate table with the field they depend on. There was a field in the project table called
portfolio from the last example. Portfolio_Name was dependant on the field Portfolio and this
27 | P a g e
caused the same information to be repeated. To be made into 3NF, that information was added
into another table and no information was repeated.
3NF Example:
Employee_Table
empID firstName lastName Email phoneNum
1 Andrew Packard Email 555-543-123
2 Daniel Plante Email 555-213-123
Project_Table
projID projName projDesc projCost Portfolio (Fk)
1 Project 1 A Project $100 1
2 Project 2 Another one $500 1
Portfolio_Table
Portfolio Portfolio_Name
1 Portfolio 1
2 Portfolio 2
Having RISC’s database in 3NF solved many update anomalies and avoided redundant data. The
entire entity relationship diagram can be found in the appendix.
28 | P a g e
6c. Layout Design
In the interviews with the project managers one requirement stressed was the ability to
easily and quickly get risk information for both the project and the portfolio. To do this a “drill-
down” system was created. Drilling down essentially means complexity is hidden from the user
by only exposing one layer at a time. Figure 9 illustrates this concept showing an inverse
relationship between layer of detail and how much of the overall picture is being calculated.
Layer of Detail Overall Picture Calculated
Portfolio
Project
Task
Risk
Figure 9. Illustrates the “Drill-down” technique used in RISC.
A portfolio has many projects which has many tasks. A portfolio will have all projects and their
respective tasks calculated into a single risk exposure. This gives the overall “big picture”
without overcomplicating the report with many details. Should the user require more details,
they can drill-down and get a more acute scope and more details. For example, assume a
program manager has three portfolios. Each portfolio has six projects and each project has ten
tasks, which is a very small project by any large business standard. That means there are sixty
29 | P a g e
tasks per portfolio for a total of 180 tasks each with their own interdependencies and
probabilities. If each task has three risks, that’s 540 risks to monitor! The program manager
should not have to struggle to find out exactly what the risk exposure is for the entire portfolio,
so only the portfolio’s exposure is shown. The program managers can then examine each
portfolio’s projects separately and get the exposures for each. From there each project can be
drilled into and all tasks are shown. As stated before, the primary goal of RISC is to expose all
high impact risks. To avoid the issues with hiding complexity, a notifications system is used to
tell the program manager exactly what risks are about to trigger and what the impact is.
6d. PHP and MYSQL
RISC is designed around PHP version 5 [14] and MySQL version 5.1 [15] and set up on a
Microsoft Windows XP Professional© [16] system with Apache 2.0.1 [17] HTTP Server. RISC
uses the Symfony framework (explained further in the next section) which requires several PHP
plugins. These plugins include: PEAR (PHP Extension and Application Repository) [18], PDO (PHP
Data Objects) [19], PDO MySQL, and MySQL. All of these extensions are included with PHP and
must be activated in the php.ini file. Once the design and the development machine were
prepared, updated, all packages installed, and all web services linked, Symfony was installed.
6e. Symfony
Symfony [20] is a PHP5 framework that uses a model-view-controller (MVC) setup. The
MVC is a design pattern that isolates model logic from the view without affecting the other.
Essentially the view is a graphical representation of the model, and does not need to calculate
logic to represent the model [21]. By separating this, a controller facilitates communication
30 | P a g e
between the model and view. As shown in figure 7, a user sends a request to a server with an
active controller waiting for an HTTP request. From there the controller sends a demand for
data and the model sends back its response to the controller. The data is then sent to the view
to be correctly displayed to the user where it may be interacted with or viewed.
Figure 7: A very basic MVC use-case/design as it works with web applications
Before starting it is important to understand that Symfony runs in three different
modes: debug, development, and production. RISC was created in development mode which
using the frontend_dev.php page (http://address/frontend_dev.php/somepage) to view the
pages will show the stack traces and very vulnerable information that can compromise security.
Once the project is completed, setting Symfony to run in production mode will suppress all
vulnerable data and show no stack traces, effectively hiding all backend data from the user.
31 | P a g e
For Symfony to work correctly, it must understand the entire database structure and its
relational diagrams. This is done by translating the ERD previously created into a YAML [24]
parse friendly (data serialization) format called a schema. The schema is then read and the
entire project base classes are scaffolded in MVC friendly stubs and helper classes. Symfony
allows for all methods to be overwritten or overloaded by working in classes that extend the
base classes. For instance, from the ERD (See Appendix A) the project table has several fields
and dependencies. Once the project has been created, symphony starts by making very generic
forms and filters for each of the tables. To change the way the forms and their respective filters
(error checking) works, the classes that extend the base can be edited and the look and feel will
be overwritten. All parts of the Symfony MVC work this way. Once the project has been
created, each table can be created into a module. This module is the frontend view and view
controller. These files can be overwritten to control the adding, editing, and deleting of
information into the table and its dependencies. RISC is broken down into several modules that
each of the three user access levels (Admin, Program Manager, and Project Manage) can
interact with differently, lowering unnecessary code and keeping repeated code to a minimum.
7. RISC – Modules and Functionality
RISC is broken into six modules: Users, Portfolios, Projects, Tasks, risks, and
Notifications. Each module contains the same parts according to the MVC design pattern:
• View – each module contains webpages that allow the user to interact with the
model via forms. The interaction includes create, edit, delete, and view.
32 | P a g e
• Controller – Symfony actually allows for a multi-controller MVC environment. Both
the view and the model get their own controllers to handle web requests and
business logic. The view’s controller is called Actions. Depending on the action of the
user the module will display the corresponding view. The actions class invokes the
controller that demands directly with the models.
• Model - To handle the business logic a model is used to contact the database via
user request and handle all data transfer to the controller in direct contact with the
model.
7a. RISC Module: Users
The users module has several functions, that is its name would describe, have to do with
the users of RISC. Its responsibilities include the creation, editing, and deletion of user accounts
and the secure authentication of users into the system. This module holds all user info and
instantiates the credentials that allows for page and content permissions. To establish
credentials an authentication system is in place. When a user is created their password is
encrypted using a hash of their password and their last name. This process can be cracked by
precomputation and memorization [25]. To prevent insecure hashes a password can be “salted”
before turned into an md5 hash. Not only is the password stored in the database, but also a
salt. The salt was calculated by taking a random number between 100,000 and 999,999 and
appending both the username and last name to the number. That string was then turned into
an md5 hash and stored. The salt and the user’s password are appended and the SHA-1
algorithm is applied, creating a forty-one character long string as the encrypted password. For
33 | P a g e
instance using the applied technique the password “test” turns into
“ff2e18de545cf2dcf35a249460f5ebf4ea62a38f” with a salt value of
“c3138652c27037a2e35bce683298647c”. To check for authentication two checks are made.
The first being if the username is found, its stored salt value is accessed. The second is a SHA-1
comparison of the salt value appended to the attempted password. If the encrypted password
matches with the attempted input, the user can officially log in and credentials are assigned.
The three credentials are admin, program manager, and project manager. Each module is
interacted with differently depending on the type of user. In the users module only the admin
may create, add, or modify users. The other two credentials only allowed read-only viewing.
A user may change their password. When that happens a new salt is assigned and stored.
7b. RISC Module: Portfolio
The portfolio module is responsible for all changes made to portfolios. It is broken into
the following sections based on credentials:
• Admin – May edit, delete, create, view or reassign all portfolios
• Portfolio Manager – May only edit, delete, create, or view portfolios assigned to this
user.
• Project Manager – Is not allowed access
The portfolio module is the very top of the “drill down” layout schema talked about previously.
Since a portfolio manager has access to an abundance of information about every project, this
module is important for giving the program manager a quick overview of the risk exposure of
34 | P a g e
each portfolio. Since RISC is a communication tool it is very important that the upper
management see how the project management is handling risks. The next layer is the project
module.
7c. RISC Module – Project
At the project module all changes to the project are made. It is broken into the following
sections based on credentials:
• Admin – may create, edit, delete, and assign projects in all portfolios
• Program Manager – may create, edit, delete, and assign projects only in their assigned
portfolios
• Project Manager – May create, edit, or delete a project which are automatically
assigned to them. When a project is created it is not assigned to any portfolio, but
shows up on the portfolio module and may be added to any portfolio(s).
The project module is the second layer of the drill down, showing all the information for each
project. The tasks and risks are still hidden from the user until a drill-down occurs.
7d. RISC Module – Task
At the task module all changes to the tasks are made. It is broken into the following
sections based on credentials:
• Admin – may create, edit, and delete tasks in all projects
• Program Manager – may only view tasks within a project
35 | P a g e
• Project Manager – May create, edit, or delete a task. They may only create tasks to
projects they are assigned to
The project module is the third layer of the drill down, showing all the information for each
task. Tasks are color coded based on their impact multiplied by their probability. The result is a
monetary estimate of damage should the task fail. The final module within the drill down is the
risk layer.
7e. RISC Module – Risk
At the task module all changes to the tasks are made. It is broken into the following
sections based on credentials:
• Admin – may create, edit, and delete risks in any task
• Program Manager – may only view risks within a project
• Project Manager – May create, edit, delete, or assign a risk to a task. They may only
create risks to projects they are assigned to
The project module is the last layer of the drill down, showing all the information for each risk.
Risks are color coded based on their impact multiplied by their probability. The result is a
monetary estimate of damage should the risk trigger. The risk trigger is a very important date
that is recorded. Depending on the preference of the Program manager, any risks that break
the threshold are reported by the notification module.
7f. RISC Module – Notification
36 | P a g e
The notification module is a unique module because each notification is an automated
message that are reported to program managers should a risk be added with a dangerous
impact potential (past the designated threshold). The threshold is decided on two part basis,
the program manager and the portfolio. The program manager can have unique thresholds for
each portfolio that will cause a notification on a task parameter. The parameters for a threshold
are potential cost (monetary loss), severity of impact (catastrophic, high, medium, or low), and
how many days before the risk trigger should they be notified. By default, all high impact tasks
will notify the program managers seven days before trigger.
8. Conclusions
In a world were poor risk management is the cause for global recession and global
financial crisis [27] a software developed to keep communication between project managers is
key to increase success rates. By forcing proper risk management protocol and monitoring the
risks triggers a business can determine the difference between acceptable risk and not
acceptable and make more rational choices about protecting its assets. Project management is
an ever growing field and as such a higher need for responsible and rational choices will
demand software to help a global world communicate. There is no one way, or definite way to
estimate risk. RISC and other future software will continue to measure risk in multiple ways to
give an accurate portrayal of risk damage, probability, and tolerance levels an organization is
willing to adopt.
37 | P a g e
While future project managers may handle risks and risk theory differently, it is clear
that there will always be a need for it. Software such as RISC will be an important aspect in
retaining information and complex calculation of risk.
9. Future Possibilities
RISC has many future possibilities and extensions to increase its usefulness across any
business. Some possibilities include:
• Parse exported Microsoft Project© files (as XML) and add them directly into RISC and
project managers will only have to add risks to each task. Parsing the XML file will
include adding the critical path and tasks automatically
• Add more project module features, such a more interactive way to edit and add tasks.
This can be done using a visual or drawing package that allows to stack and show
dependencies
• Expand the communication by adding skype™ features that allow for direct
communication between managers.
• Add the ability for a MS Project file to be uploaded so anyone can download the file and
view how the project was handled
• Add all risk exposure features (PERT, Expected Value, and PERIL) and let the user decide
which ones are relevant to their trusted risk tolerance
38 | P a g e
10. References
[1]Duhigg, Charles “Pressured to Take More Risk, Fannie Reached Tipping Point” New York
Times. October 4th 2008.
[2] Construction Industry Institute, “Management of Project Risks and Uncertainties” University
of Texas at Austin, October 1989.
[3] D.C. Fraser, “Risk Minimization in Giant Projects, International Conference on the Successful
Accomplishment of Giant Projects” London, England, May 1978.
[4] Project Management Institute, 1992, “Project & Program Risk Management: A Guide to
Management Project Risks & Opportunities” Project Management Institute, Inc. Newtown
Square, PA 19073
[5] Gido, Jack and James P. Clements “Successful Project Management” Fourth Edition. South-
Western, Ohio, 2009.
39 | P a g e
[6] After D.T. Hulett, PMP Certification Workshop – Risk Management, PMI Orange county
Chapter, 1991.
[7] Project Management Institute, 2004, "Project Management Body of Knowledge, Fourth
Edition, (PMBOK Guide), Project Management Institute, Inc. Newtown Square, PA 19073
[8] Woolf, Murray B. Faster Construction Projects with CPM Scheduling. McGraw Hill. Critical
Path method. 2007.
[9] Churcher, Clare. Database Design. Apress, New York. 2007.
[10] Codd, Edgar F. “A Relational Model of Data for Large Shared Data Banks.” Communication
of the ACM: 13 (6): pp. 337-387. June 1970.
[11] Packard, Gregory C, PMP and Jeffrey Haught, PMP. Interview. 8 Nov 2008.
[12] Soodek, Andy “PPM Tool Selection and Implementation Considerations”, PMI Virtual
Library http://www.pmi.org/PDF/Members/Soodek_2008.pdf 2008.
[13]Colodzin, Michelle “The Five Secrets of Project Scheduling”, PMI Virtual Library
http://www.pmi.org/PDF/Members/Colodzin_2008.pdf, 2009
[14] PHP 5 – http://www.php.net
[15] MySQL 5.1 - http://www.mysql.com/
[16] Windows XP Professional - http://www.microsoft.com/windows/windows-xp/
[17] Apache 2.0.x - http://httpd.apache.org/docs/2.0/
40 | P a g e
[18] PEAR - http://pear.php.net/
[19] PDO - http://us.php.net/pdo
[20] Symfony - http://www.symfony-project.org
[21] Burbeck, Steve “Applications Programming in Smalltalk-90: How to use Model-View-
Controller (MVC)” University of Illinois. 1992. http://st-www.cs.uiuc.edu/users/smarch/st-
docs/mvc.html
[22] Packard, Gregory C, PMP. Interview. 12 March 2009.
[23] Verdon, Denis and Gary McGraw “Risk Analysis in Software Design” IEEE Security & Privacy
May/June 2004. http://www.cigital.com/papers/download/bsi3-risk.pdf
[24] YAML - http://www.yaml.org/
[25] Morris, Robert and Ken Thompson. “Password Security: A Case History” Communication of
the ACM: 22 (11): pp. 594-597. Nov 1979.
[26] Ozog, Henry “Designing an Effective Risk Matrix” ioMosaic New Hampshire. 2002.
http://archives1.iomosaic.com/whitepapers/risk-ranking.pdf
[27] Baily, Martin Neil, Litan, Robert E., and Matthew S. Johnson, The origins of the Financial
Crisis. Brookings Institution. Washington, DC. Nov 2008.
[28] McCaffrey, James “Software Testing: Analyzing Project Exposure And Risk Using PERIL”
MSDN Magazine: 1. Jan 2009.
41 | P a g e
[29] Berrett, Bruce E and F. Hutton Barron. “Decision Quality Using Ranked Attribute Weights”
Management Science: 42 (11): pp 1515-1523. 1996.
[30] Jianmin Jia, Gregory W. Fisher, and James Dyer. “Attribute weighting methods and decision
quality in the presence of response error: A simulation study” Journal of Behavioral Decision
Making. April 1997.
Appendix A
Software Requirements Specifications – Adaptation of IEEE Standard 830-1998
(Revision 5) 4/07/2009
1. Introduction 1.1 Purpose: The purpose of this document is to define the requirements for a software application to provide a means by
which upper level program management can quickly view overall
effectiveness of risk mitigation strategies and risk assessment for a
portfolio of projects being managed by an organization.
1.2 Document Conventions: All top priority requirements will be in bold typeface.
1.3 Intended Audience: Program management and project managers
1.4 Contact Information: Andrew Packard, Designer and Programmer
1.5 Scope: The scope of this project is to provide a means by which Program Management can obtain an overall risk exposure for the
entire portfolio of projects that they are responsible to manage.
1.6 References: Greg Packard, PMP & Jeff Haught, PMP 2. Overall Description 2.1 Product Perspective:
Risk Monitoring and Control: To rate effectiveness and maintain
the archived risk memory of past projects. At this point, project
42 | P a g e
managers have already done their analysis, planning, and
mitigation strategies. Now the projects are turned into a portfolio
that is under an upper management program manager.
2.2 Product Functions: a. Risk Register – lists risks with associated mitigations.
b. Risk Exposure- Portfolio’s worst case, best case, and average
(most likely) case monetary damage estimates
c. Searchable – find portfolio and project attributes through
keyword search
d. Notification System – risks requiring attention
e. Watchlist – listing of all risks based on threshold and user
class
f. Admin Section – super-user controls
2.3 User Classes and Characteristics a. Project Manager – Lowest level of control over a project
domain. Assigned a single project to maintain and their user
options are decided by Program Managers and Admins. They
are allowed to view any past projects at all times and are
allowed to search through the risk memory section.
b. Program Manager – High level of control over a portfolio
domain. Portfolios have a higher level of overall detail. They
are given Risk Exposure functions and can view any and all
information within their portfolio. This user decides how the
portfolio’s process assets will be defined. The program
manager can comment on any project within their portfolio,
and edit all details in all portfolios.
c. Admin – Highest level of control over the entire domain. This
user can add accounts, assign accounts, give permission levels
2.4 Operating Environment: a. PHP (v4.x) and MySQL(v5.x) within Internet Explorer 7.x,
Firefox 3.x, and Safari 3.x or higher. Operating system is
irrelevant. Database can be held on any compatible OS.
2.5 Design Constraints: This is a web based application, and assumes an internet connection with the ability to connect to a WWW
address is available. The database machine must be able to handle
as many projects as the portfolio requires. Overall database traffic
is presumed to be low on editing and adding data, but high on
search queries.
2.6 Assumptions & Dependencies a. Dependency: PHP and MySQL packages will continue to be
supported and updated during the creation and maintenance of
this software
b. Assumption: W3C standards will not drastically change
during the software creation
3. System Features 3.1 Risk Register - Project managers input their risks, which includes
an exposure (probability and damage amount) given their previous
analysis and that is saved to the database.
REQ1: Risk registers hold all changes made to a risk and the
43 | P a g e
persons responsible.
REQ2: Once a risk is evaluated it is moved to the archived risk
register (known as Risk Memory)
REQ3: Risks are ordered as a networked diagram showing
dependency and most risky path
3.2 Risk Exposure: Once a portfolio of projects is created all projects
will use an active risk register to indicate monetary damage
estimates. These estimates include a pessimistic, optimistic, and
most likely cost, based on probability. Impact is estimated cost in
damages made by risk. The pessimistic cost is a likely worst case
and generally has the highest possible impact. The optimistic is a
likely best case and generally has the lowest impact. The average
case or better known as the ‘most likely’ case is the project
manager’s best judgment of possible impact.
REQ1: Risk exposure is on two levels; the project manager can see
their own total risk exposure and entire portfolios have a risk
exposure
REQ2: The program manager can view individual project’s risk
exposures
3.3 Searchable – all risks once properly evaluated will be stored in an
archive risk register. This archive can be searched by anyone
within the company and all details are shared. Both the active and
archived risk registers can be searched and the Project/Program
manager’s information is available for contact.
REQ1: Two separate databases to search, active risk register and
risk memory.
REQ2: Program Managers can search within their portfolios
3.4 Notification System – both Project and Program managers can be notified of different details.
a. Project managers must be notified whenever any change was
made by the program manager or admin to their project. They
must be notified when a risk trigger is about to occur.
REQ1: Notifications will tell why they were notified, when,
and have a color scheme or icon scheme associated.
REQ2: Risk trigger notifications will be set by the project
manager’s options. Only certain thresholds will give a
notification. The notification date will be set by the project
manager and will have default times.
b. Program managers are notified whenever a risk trigger above
a certain threshold is added to the active risk registry and at
certain intervals as the date approaches.
REQ1: Risk trigger notifications will be set by the program
manager’s options. Only certain thresholds will give a
notification. The notification date will be set by the program
manager and will have default times.
3.5 Watchlist – a project manager will have a list of all upcoming risk
triggers of any threshold in chronological order, secondary order
by impact strength.
4. External Interface
Requirements 4.1 User Interfaces: Data input will be forms that can be prepopulated.
GUI will take a macro viewpoint for program managers. Showing
less detail, but a “bottom line” estimate for their portfolio. Project
managers will also be shown an individual bottom line.
44 | P a g e
4.2 Software Interfaces: PHP v4.4.9 will be used and connected to MySQL v5.0. Due to the nature of the application, the
communication interface (browsers) is also the software interface
required to properly view and arbiter the flow of information
between the end user and software.
5. Other Nonfunctional
Requirements 5.1 Performance Requirements: Viewing the webpage must be quick
and non-cluttered. This includes all MySQL queries. While
database transactions are expected to be high in general query,
they are expected to be low in edits and additions.
5.2 Security Requirements: Extremely sensitive data is present and shared among a general population of users (project managers
especially). It is required to have a log in system and impossible to
hijack MySQL queries to edit, steal, or corrupt data. The
notification system to tell the project manager a change has been
made to their project by a higher level user is necessary to protect
the project integrity.
5.3 Software Quality Attributes: The options available to each user class must be expansive to allow for all types of notifications,
watchlists, and risk exposures.
Entity Relational Diagram for RISC