Risk Analysis & Management

Introduction

Why do some projects fail miserably while others are supremely successful? Of course, the greater the risk, the higher the failure rate, but
even high - risk projects have been successfully implemented. The ability to first assess and measure risk, then create/implement strategies to reduce the risk, and finally, continuously monitoring the level of risk will significantly improve the chance of success. To do this you will use a Risk Evaluation table and a Risk
Reduction Strategies table. You also must revisit this table week to week to confirm if risk reduction strategies are indeed lowering the project’s overall risk.

Description

Five basic categories of factors influence risk. They are:

  • Characteristics of the organization.
  • Characteristics of the information system.
  • Characteristics of the system developers.
  • Characteristics of internal users.
  • Characteristics of external users.

Within each category, the development team poses a series of questions to evaluate and measure the risk level by creating a Risk Evaluation table (Figure 1). Answering and scoring the questions yields insight into the level of risk and where the risk resides. Using this knowledge, the team devises risk reduction strategies and summarizes their strategies in a Risk Reduction Strategy table (Figure 2).

Purpose

Whether they are small or large, all IT projects contain risk. Our goal is to not eliminate risk but to manage it.  Using a Project Risk Evaluation Table and a Risk Reduction Strategies Table enables you to identify and put a plan in place to mitigate the risks associated with all IT projects which leads to a great chance of success.

Creating a Project Risk Evaluation Table (PRE)

To create your Risk Evaluation table first download the template from the class Resources page, rename it and save it. Answer the questions by assigning a numeric score of +1 if the risk does not exist (the answer is positive). If the risk exists, score it a -1 and if uncertain, give it a 0. Include specific comments that justify your ranking for each question. Figure 1 gives an explanation of each factor on the Risk Evaluation table.

Using this basic 5-category Risk Evaluation table, notice there are 34 possible scores ranging from -17 (extremely risky) to +17 (no risk.)

Risk Spectrum

A high final risk score (e.g. -7 or lower) is a early general warning about project risk. A high-risk score is an indication that there may need to be a change in the scope, resources, or schedule. A low-risk score should not be taken as an indication that that the project is risk free; for example, if a couple of the factors for ―system developers‖ are scored -1, then a resource issues should be address (e.g. Replace developers or budget time for training could improve category to a +1).  So, what is most important is looking at all the -1 and 0 risk factors to see if risk can be reduced, rather than only looking at the total risk score.


Figure 1.  Project Risk Evaluation: Explanation of Factors

1. Characteristics of the organization.

a. Has stable, well-defined objectives?

Organizations with missions that are undefined, chaotic, or rapidly-changing present challenges to development teams.  The information system goals may be clear, but the value to the organization will shift (or disappear) if the organization’s goals change.  Recent mergers can create risky situations if the merged businesses have conflicting objectives. Existing organizations that are re-organizing or shifting their focus will present similar challenges.

b. Does client have an existing IT Team and/or Budget for IT?

Ideally, individual projects are part of a broader plan for managing and improving technology resources.  When no clear list of prioritized IT projects exists, your project may lose funding if managers decide that other projects are higher priority.  In some cases, clients with little IT budget and resources, have to consider future investments.  Also if there is not budget for IT Support, the app’s functionality may be less due to picking a more maintainable solution.

c. Proposed system fits strategic plan and addresses organizational objectives?

From an organizational perspective, the least risky projects are those that clearly contribute to organizational objectives.

d. Executive sponsor of the proposed system has adequate authority to fund project scope?

Project scope may be compromised if the executive sponsor does not have the budget authority to fund the project with adequate staff or technology resources.

e. Does the organization experience higher than average turnover rate?

This is important to consider not only in managing resources but retaining information in how to use and maintain the app.  Are you training users that will soon be gone?  Is so, how will you manage this?

 

2. Characteristics of the proposed information system.

a. Model available or clear requirements?

Is a clear model available that guides the system development team for design, construction, and testing?  If not, has the client provided clear requirements for the proposed system?

b. Are there existing/routine processes in place?

Does the proposed system simply automate a well-structured process or do the users follow a wide variety of processes with the current system and use their own judgment for key steps?

 

c. Affects only one business area?  (No cross-functional or interorganizational links?)

Does this affect one group of people or division at your client or does it affect multiple groups?  e.g. If we're implemented an inventory management system at Frito Lay, that affects Manufacturing, Distribution, and Sales.  If we're only updating something like Invoicing, that may only affect Accounting.  

The most groups you have to involve the involve, the higher the risk.  If you only are working with on silo of the organization that's less complex and risky.

d. Can be completed in less than three months?

This answer is based on the original scope request by the client, unless the team has negotiated multiple releases.  If there are multiple releases, your comment should be clear about the scope that is the basis for the answer to this question.

e. Uses stable, proven technology?

Your comment should be clear about what software tools you are evaluating as stable and proven or not.

f. Installation at only one site?

Your comment should be clear about where the system will be installed.

 

3. Characteristics of the developers.

a. Are experienced in chosen development methodology?

In MIS 374 you are required to use an iterative development methodology.  In professional situations you are likely to be unfamiliar with the methodology of your firm for your first project, but a team lead should be familiar.

b. Are skilled at determining functional requirements?

Be clear about which developers are experienced, if any.

c. Are familiar with technology and information architecture?

A +1 score here for client projects means you are using the same environment as past MIS 333k projects and you know your clients’ information architecture—an unusual situation for MIS 374 projects. That said, there may be additional skills on your team.  Be clear about “why” for your assessment.

 

4. Characteristics of the users (Repeat this for each major user group)

a. Have business-area experience?

Does this user group have experience in the functionality required for effective use of the system?

b. Have development experience?

This question should only be included in the internal user category - for the clients who will work with you to define requirements and test your system.  External users will only be involved in the process if they are part of a focus group.

c. Are committed to the project?

Client commitment for internal users is key to learning functional and non-functional requirements early—a necessary condition for a smooth, successful development process. External users might be involved as part of a focus group to determine usability or even be involved in early requirements. Sometimes you will just have to guess about the commitment of external users.

 

Identifying Risk Reduction Strategies

Once you have identified the risks associated with your project, you should identify relevant risk reduction strategies or create a list of questions to ask to clarify whether the item is a risk to your client/project:

  1. For -1s, create specific strategies that will mitigate each risk.
  2. For 0s, create a list of questions you'll need to answer to will help determine if this is a -1 (i.e. a risk) or a 1 (i.e. not a risk).  Note that in some cases your team may rate something as a 0 because it has both some risk and unknowns which means you could have to create risk mitigations and follow-up questions.
  3. For 1s, indicate "n/a" in the risk reduction strategy cell for that risk (do not leave it empty).

Although all projects are unique, there are some recurring themes regarding risk in IT projects.  Figure 2 summarizes recurring Risk themes along with suggestions on how to reduce each type of risk.

Figure 2.  Recurring Risk Themes and Possible Risk Reduction Strategies

Examples of project risk

Possible risk reduction strategies

1a.  Newly merged organizations have conflicting unstated objectives.

Enlist high-level executives from both organizations to attend a team meeting that includes key users.  These executives must sell the value of the proposed system to users. (Notes: Developers rarely have the power to change business cultures.  Technology by itself does not solve organization dysfunction, so enlisting the appropriate organizational help is a key to success.)

2a.  System requirements are unclear.

Conduct whiteboard meetings with key users to work out the processes graphically with data flow diagrams and use cases; photo all the graphics and recreate them in Visio for user review.  Once there is an agreement on the existing process, work with the users to design well documented new processes that meet the clients’ system objectives and performance criteria.

2b.  Key users are unable to explain their processes.  They seem to do something different every week for their weekly reports.

Videotape the weekly reporting process for all key users.  Summarize these graphically as Data Flow Diagrams in Visio for user review.  Once there is an agreement on the existing process, work with the users to design well-documented, new processes that meet the clients’ system objectives and performance criteria.

3c. The development team does not know Java*, the software development tool requested by the client.

 

*this could be any unfamiliar language or platform-- Ruby on Rails, iPhone app, etc.

There are several possible solutions; all are dependent on your abilities and client situation.  Here are three possibilities.

·  Learn Java.  (The JudyPaul.com team did this, as have many past MIS 374 teams with mixed success.)

·  Create a proof-of-concept system and thorough documents and test data that can be turned over to paid programmers once the semester is over.

·  Complete the software in the tools you know from MIS 325 and 333k.  (Note that the hosts that include these tools are more expensive than the inexpensive host sites that low-budget non-profits can afford.  So, this, like all decisions, needs to be discussed with your clients.)

4b. This is the first time our client has worked with developers before.

Ask lots of questions, create lots of prototypes that your client can interact with, and write early drafts of training materials to be sure you learn the detail level of user materials required.

Benefits

Understanding the characteristics of the organization, the information system you want to develop, the developers, and the internal and external users enables you to see the strengths and weaknesses of your project before it begins.

Using this knowledge proactively by creating a Risk Evaluation table and a Risk Reduction Strategies table will help you reduce risk, thereby increasing efficiency and client “buy-in” and address areas of concern.

Tips for Completeness

  • Include as wide a range of users as possible as a way to learn the real scope of the project and help your clients consider whether risks vary across potential user-categories.  You do not have to limit yourself to the generic categories of “internal” and “external” users.
  • Use labels that are specific to your client—not “user” or “our client,” but the actual types of users and names. Notice in Figure 3, the AWS team used “Parents” and “Susan” on their AWS Project Risk Evaluation Table.
  • All your risk reduction strategies should be appropriate for your clientFor example, hiring programmers to add to your team is not appropriate.    

FAQs

Q1. What if we don’t know if our client has a budget or plan for IT resources? Answer: Ask them and make sure you use terminology they understand.  e.g. Do you have dedicated IT staff?  Do you have other future IT projects planned?  Do you have a preferred platform you choose to use/support?  Do you have a dedicated budget for IT projects?

Q2.  Are the system category questions about the existing system or the proposed system? Answer:  The focus is on the proposed system, but the existing system is often relevant when you consider your answer.  In the ICC Project Risk Evaluation Table provided as an example on the Resources page of the class website, the team scored Factor 2a. as -1 because the existing system did not provide a clear model.  Note that the ICC Risk Reduction Strategies Table (also on the Resources page) indicates that the team planned to reduce this risk by videotaping the ICC staff going through their process, thus creating a clear model that did not exist at the beginning of the project.

Q3. How do you “monitor” risk continuously? Answer: Remember that the goal of this exercise is not just to identify the risks and be done.  You team should be sure to address risks with a reduction strategy. Ideally, your overall risk score should go down if your reduction plans are working or at least remain static.  Try adding a consistent agenda item each week to “Rescore/Review Risk”.  Each week in your team meetings, the Project Manager and team should be asking “Is our risk being properly managed?”.


Templates and Examples