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

45 | P a g e

RISC – Login Page

46 | P a g e

RISC – Example Portfolio List

47 | P a g e

RISC – Example Project Listing For A Portfolio

48 | P a g e

RISC – Example Project Edit Page

49 | P a g e

RISC – Example Project Info

50 | P a g e