CprE 329 Project Management

HW 7 Risk Management Plan

Edwin Martinez

Table of Contents

Introduction3
Personnel Shortfalls.3
Unrealistic Schedules and Budgets...4
Developing the Wrong Software Functions..5
Developing the Wrong User Interface...6
Gold Plating...7
Continuing Stream of Requirement Changes..8
Shortfalls in Externally Performed Tasks..9
Shortfalls in Externally Furnished Components...9
Real-Time Performance Shortfalls..10
Straining Computer Science Capabilities...11

I.

Introduction
The purpose of this risk management is to identify risks and plan for mitigations.
A risk is an event or condition that, if it occurs, could have a positive or negative
effect on a projects objectives. Risk Management is the process of identifying,
assessing, responding to, monitoring, and reporting risks. This Risk Management
Plan defines how risks associated with the project will be identified, analyzed,
and managed. It outlines how risk management activities will be performed,
recorded, and monitored throughout the lifecycle of the project and provides
templates and practices for recording and prioritizing risks.

II.

Personnel Shortfalls
A possible problem in our project could be personnel shortfalls. This could be
when our team lacks trust in each other, lets ego gets in the way, or lacks the
training and experience to succeed.

a. Identification
To identify this problem we make sure to check in with each member at
team meetings and measure everyones progress and teamwork
effectiveness. In my project of one person, to identify this problem is more
challenging. I must make sure to be ahead of the curve and on top of all
tasks.

b. Risk Factors
i. Likelihood
The probability of this happening is high. This is because as a one
person team, if something happens to me or I fall short, the whole
project will be affected.
3

ii. Impact
This risk also creates a very high risks because of been a one
member team.

c. Mitigation/Minimization Plan
Because this is a high likelihood and high impact risk we must plan to
mitigate it. To avoid personnel shortfalls I could hire new top talented team
members, practice relaxation techniques and go through some training
and tutorials. This would minimize personnel shortfalls in my project.

III.

Unrealistic Schedules and Budgets

Having unrealistic timelines and a bad budget to go with it can completely
destroy the scope of the project. By having a bad schedule can make your
project take too long to develop and never finish it. Having a bad budget can
result in underpaid team members or not enough resources for assets
required for completing the project.

a. Identification
To identify this we must look at the timeline developed and compare them
to other similar projects. If the time to complete the project is too big or
past the desired deadline goal, then we must reassess the schedule. For
budgeting we must look at the schedule and determine how much we are
willing to invest in this project. If the resulting budget is beyond what we
are willing to invest in, then we must lower the scope.

b. Risk Factors
i. Likelihood
The probability of this happening is very low since we have a very
clear schedule plan of four weeks. Im not getting paid and we do
not need financing for any technology or resources needed.
4

ii. Impact
This risk has a very low impact. Since there is no budget required
and the scope is strictly limited and very well defined. The only
thing that could happen is that if the schedule isnt follow then
unrealistic changes will have to take place.

c. Mitigation/Minimization Plan
To mitigate this possible risk, we must adhere to the established schedule
and budget. Since the budget is zero, there is no worry for that. As for the
schedule I just have to be sure not to slack off and accidentally increase
my schedule time.

IV.

Developing the Wrong Software Functions

It is important for our project to make sure we deliver the correct product with
the correct functions. Otherwise we wasted our time and made the wrong
product.

a. Identification
To identify this risk we must see if our requirements correctly meet the
clients needs. If we start making features that do not solve the clients
problem, then we need to re-evaluate our requirements.

b. Risk Factors
i. Likelihood
The probability of this risk happening is medium. This is because
the client has defined a vague requirement, even after continues
communication.

ii. Impact

This has a high impact on the project. Delivering a product with the
wrong features is gives the client nothing of what they wanted,
costing them money and resources and derailing our results.

c. Mitigation/Minimization Plan
To avoid this we can mitigate in several ways. We can continuously
analyze our requirements and communicate with the client to ensure we
make the correct features. To crosscheck we must do some organizational
analyzes and see how the product solves the clients problems.

V.

Developing the Wrong User Interface

Just like making software with the wrong features affects the end product,
making the wrong user interface will make it difficult and more tedious for our
costumer to interact with our product.

a. Identification
We can identify this problem by analyzing if the interface makes sense,
i.e., the flow from tasks to tasks is seamless, easy to use, and obvious. If it
takes longer to use the product than how the client solves the problem
currently, then we need to rethink this. Also if users can flow through use
cases, then we must also realize we may have made the wrong UI.

b. Risks Factors
i. Likelihood
The probability of this happening is low because we make sure to
make prototypes, screen sketches, and use cases to double check
that we are making the correct UI.

ii. Impact
The impact is high because just like the risk of having the wrong
features, having the wrong UI makes the product useless and a
waste.
6

c. Mitigation/Minimization Plan
To avoid this risk we must make sure the prototypes and the screen
sketches are well made and what the client wants. This is done by
keeping up communication with the client to see if this is what they want
and achieves the desired task in a measureable and more efficient
manner than before.

VI.

Gold Plating
When polishing the product we must beware of adding unnecessary features
that are added simply for the sake of making the product look better. This
ends up been a waste of time, money, and resources by our team.

a. Identification
While developing we must always look back at our requirements to and
ask if we really need this feature. If I start developing a component that is
not cost effective and has little impact on the project, then we must contain
this risk.

b. Risk Factors
i. Likelihood
The probability is low because as a one person team I can hardly
afford to add things for the sake of making the product look better.

ii. Impact
The impact is medium because if I do add a new feature and fully
implement it, it will add to the scope of the project; however this will
come at the cost to the budget and resources for other
components. This can also be a double edge sword, as adding
something for the sake of looking nice might not communicate well
with the client and reflect negatively on the developer.
7

c. Mitigation/Minimization Plan
To mitigate these risks we can do the following: Requirement scrubbing,
removing the unnecessary things. Do some cost benefit analysis, to see if
the feature has any merits been used. Lastly we must design components
within the budget.

VII.

Continuing Stream of Requirement Changes

With a dynamic project requirements are always changing to adapt to new
needs and challenges. This creates a potential risk of never achieving the
goals set out by the team and never finishing components.

a. Identification
We can recognize this risk when requirements keep getting changed
before things can get finished.

b. Risk Factors
i. Likelihood
The likelihood of this happening is high, since the needs of the
client can always change. In my project, the client can ask for a
function to perform the tasks in a different manner at any point in
the development cycle.

ii. Impact
This hard a high impact on the project as it delays the deadline to
complete the project. This can also yield in frustration to the team
members.

c. Mitigation/Minimization Plan
To minimize this risk we can set a high change threshold, practice
information hiding, and defer changes to later increments. By doing this
8

we can organize ourselves accordingly and be prepare for likely changes

in the requirements.

VIII.

Shortfalls in Externally Performed Tasks

Externally performed tasks can greatly affect the efficiency of the product as
well as set the basic architecture of the components. Such as subcontractors
or users dont do whats needed.

a. Identification
We can identify these risks by doing some inspections of how the external
tasks interact with the core functions. If we start noticing some
compatibility issues, then we must take action.

b. Risk Factors
i. Likelihood
The likelihood of this happening is medium in our project since Im
dealing with the user input and bank payment components.

ii. Impact
The impact is low because the project is design around this
problem. The only meaningful impact would be issues with payment
subcontractor.

c. Mitigation/Minimization Plan
To minimalize this problem we can do some reference checking,
especially looking into pre-awards audits and award fee contracts. Lastly
review for competitive design and prototyping.

IX.

Shortfalls in Externally Furnished Components

This risk comes from hardware or software dependencies, such as hardware
limitations or inadequate software libraries.
9

a. Identification
These risks can come up when we dont have the users systems in mind.
It can be identify by noticing that we did not take the users hardware and
software information and by noticing that the project wont work on the
platform.

b. Risk Factors
i. Likelihood
The probability is low due to the fact that we plan on using already
well established platforms.

ii. Impact
The impact of these risks would be high though. This is because we
would have to refactor to have our product running on the target
platform.

c. Mitigation/Minimization Plan
To mitigate these risks we will perform benchmark testing, do inspections,
reference checking, and lastly and most importantly, do compatibility
analysis.

X.

Real-Time Performance Shortfalls

This issue occurs when some or all of the systems begin to cause a bottle
neck effect, slowing everything down and eventually crashing.

a. Identification
We can identify this issue with multiple forms of testing and analysis to
see how the system runs.

10

b. Risk Factors
i. Likelihood
The likelihood of this happening is low because our project only
performs few tasks per screen. It could only happen if the system
ends up with traffic too high for the server to handle.

ii. Impact
The impact is medium because if the product falls short and doesnt
run efficiently or even crashes, then our clients and their costumer
will ruin our credentials and lose business.

c. Mitigation/Minimization Plan
The mitigate this we must plan ahead and perform a gauntlet of test
including: benchmarking, simulations, modeling, prototyping,
instrumentation, and some fine tuning.

XI.

Straining Computer Science Capabilities

This risk is the result of unstable or unfamiliar technology been used for the
project.

a. Identification
This risk is identified by looking at how ambiguous the scope and
technology been used is. Also by how unfamiliar the developers are and
by how limited you are with current technology trends.

b. Risk Factors
i. Likelihood
The likelihood in this project is low because what Im working on
has been done and replicated before, however I have to make sure
I do my research and understand the computer science concepts.
11

ii. Impact
The impact on this project is also low because Im not doing
anything that pushes the limit, rather just replicating products that
are already in the marker. But should this risk emerge, it will result
in time lost in refactoring and lowering the scope.

c. Mitigation/Minimization Plan
The key things to mitigate this are by doing some research, technical
analysis, cost benefit analysis, prototyping, and reference checking.
Basically just make sure that when planning this project that it can be
completed.

12