Identifying and Managing Risk in Software Projects, Explained

UPI Study › Courses › Software Engineering › Free lessons › Lesson 13.1 Free with a free account

Identifying and Managing Risk in Software Projects

Software Engineering · Chapter 13: Project Management, Planning, and Agile GovernanceSection 13.1 · lesson 80 of 1036 min · free with a free account

← Putting Network Security to the TestNext lesson: Planning a Project: Processes, Tools, and Techniques →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

Dealing with potential problems deliberately - before they become actual ones.

  • Define a risk, and distinguish it from an issue
  • Describe the 4 stages: identify, assess, mitigate, and monitor
  • Prioritize risks by probability and impact together
  • Explain why risk management is an ongoing cycle

Transcript

Everything said in the video, section by section (768 words). Read along, or search it.

Project Management, Planning, and Agile Governance

Identifying and Managing Risk in Software Projects

Projects rarely fail because of one dramatic event that nobody could have seen coming. This section covers risk management. How risks are identified, assessed, planned for, and tracked throughout a project.

Predictable in Hindsight

Why Projects Actually Fail

Far more often, a project fails because of a problem that was, in hindsight, entirely predictable. A key person leaving. A technology that turned out to be unready. Requirements that never stabilized. And nobody planned for it. Risk management is the discipline of dealing with these potential problems deliberately, before they become actual ones. The alternative is reacting to them only after they arrive.

Risk vs. Issue

What Is a Risk?

A risk is a potential future problem. It is an uncertain event that has not happened, and may never happen, but would create real consequences if it did. That is different from an issue, which is a problem that has already occurred, and now needs to be resolved. Every risk can be described along two dimensions. How likely it is to happen, and how serious the consequences would be if it did. Both matter. A very unlikely risk with severe consequences, and a fairly likely risk with mild ones, can both deserve real attention, for different reasons.

The Cycle

Identify, Assess, Mitigate, Monitor

Risk management runs as a continuous cycle, with four stages. Identification surfaces potential risks before they become problems, drawing on past projects, structured checklists, and open discussion with the people closest to the work. Assessment estimates each risk's probability and impact, so that limited attention goes to the risks that genuinely warrant it. Mitigation plans concrete steps to reduce a risk's probability or impact, before it materializes. And monitoring keeps watching for early warning signs, reassessing priority as circumstances change. What monitoring finds becomes new input for identification. So the cycle never simply ends.

Table 13.1

The Cycle at a Glance

Here is the cycle at a glance, with what each stage produces. Identification produces a list of candidate risks. Assessment produces those risks, ranked by priority. Mitigation produces a plan for each high-priority risk. And monitoring produces an updated risk status, which feeds straight back into identification.

Figure 13.1B

Probability Times Impact

Not every risk deserves the same attention. Plotting each one by probability and impact shows which ones need a real plan. A risk with both high probability and high impact deserves an active mitigation plan, without delay. A risk with high impact but low probability still deserves close attention. Being unlikely does not make its consequences any less severe. A fairly likely risk with mild consequences can still deserve attention, for a different reason. And a risk low on both dimensions can often be accepted and simply tracked, leaving effort for the risks that need it more.

Bringing It Together

The RMMM Plan

The output of this process is often kept as a single living document, called an R M M M plan. That stands for risk mitigation, monitoring, and management. It records each risk, its assessed probability and impact, and the mitigation steps planned to reduce it. It also holds a contingency plan, describing what the team will actually do if the risk occurs anyway. And like the cycle it documents, the plan only stays useful if it is revisited and updated throughout the project.

Think About It

A Risk You Could Have Seen

Think about a group project you have worked on, academic or otherwise. Name one risk that, looking back, was predictable early on. Where would it have landed on the probability and impact grid? And what mitigation step might have reduced it?

Apply It

Written at Kickoff, Never Opened Again

Let's apply that. A project team writes a thorough R M M M plan at kickoff, and never looks at it again. What is likely to go wrong? New risks never get identified, because the cycle has stopped. Priorities go stale as circumstances change, and early warning signs go unwatched. Before long, the plan describes a project that no longer exists.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. A risk is a potential future problem. An issue is a problem that has already occurred, and now needs resolving. Risk assessment estimates a risk's probability and impact, to prioritize it. Risk mitigation plans concrete steps to reduce either one, in advance. Risk monitoring is the ongoing tracking of identified risks, watching for early warning signs. And an R M M M plan is a living document recording each risk's assessment, mitigation plan, and contingency plan.

Key Takeaways

What to Carry Forward

To pull this together. A risk is a potential future problem, while an issue has already happened. The risk management cycle has four stages. Identify, assess, mitigate, and monitor. And it keeps repeating. Risks are prioritized by probability and impact together. A risk that is unlikely, but severe, still deserves close attention. And an R M M M plan is a living document, kept current for the life of the project.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Identifying and Managing Risk in Software Projects

What is the difference between a risk and an issue in project management?
A risk is a potential future problem that has not happened and may never happen, while an issue is a problem that has already occurred and needs resolving. Every risk can be described by how likely it is and how serious its consequences would be. Managing risks means acting before they become issues instead of reacting after they arrive.
What are the four stages of software risk management?
The four stages are identification, assessment, mitigation, and monitoring. Identification surfaces candidate risks using past projects, checklists, and discussion with people close to the work. Assessment estimates each risk's probability and impact to rank it. Mitigation plans steps to reduce probability or impact in advance. Monitoring watches for warning signs and feeds new findings back into identification, so the cycle repeats.
How should project risks be prioritized?
Risks are prioritized by looking at probability and impact together. A risk high on both needs an active mitigation plan right away. A high-impact, low-probability risk still deserves close attention, because being unlikely does not soften its consequences. A likely risk with mild effects can also merit attention, while a risk low on both can often be accepted and simply tracked.
What is an RMMM plan?
An RMMM plan is a living document for risk mitigation, monitoring, and management that records each risk, its assessed probability and impact, and the planned mitigation steps. It also holds a contingency plan describing what the team will do if the risk occurs anyway. A common mistake is writing it at kickoff and never reopening it, which lets priorities go stale and new risks go unnoticed.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →