Section 4 · Risk Management
On this page 9 headings
A risk is a possible future unfavorable event. It is worth managing before it happens: after a problem has already caused a delay, the team is responding to an incident rather than anticipating a risk.
Why risks are harder to see in software
The lecture defines a project risk as an anticipated unfavorable event that may occur during development. When a house is built, the construction manager can see every stage — foundation, slabs, frame, roofing, interiors, painting — and assess and control progress. Software is intangible, so it is difficult to control something we cannot see.
Examples include a syntax error that disrupts a larger system, vulnerable components, disagreements within the development team and unexpected delays. The project manager identifies, assesses, mitigates and continues monitoring such risks rather than assuming everything will go according to plan.
Three categories: technical, project and business
Technical risks are risks related to the technical aspects of the project, arising from the development team's insufficient knowledge about the product; they can occur at any stage — requirements, design, implementation, testing or maintenance. Project risks occur due to problems in budget, schedule, personnel, resources and customer-related problems — all non-technical risks are project risks. Business risks are risks which can harm the business aspects of the software product.
Technical risk: misunderstood requirements
The team may develop the wrong functions or user interfaces, mainly because the requirements received from the client are ambiguous or incomplete. Ambiguity or incompleteness in requirements can cause incorrect user interfaces, workflows and implemented features.
The mitigation described in the lecture is regular client communication and early prototypes. Demonstrate a small version, ask stakeholders whether it matches their needs, and refine before investing heavily in the wrong design.
Technical risk: external software components
External libraries, cloud services and vendor modules can be unreliable, incompatible, slow or vulnerable. Depending on a component transfers some work to another supplier, but it also creates a risk outside the team’s direct control.
Benchmark candidate components and inspect them periodically.
Project risks: slippage, missing expertise, staff departures
If milestones slip, a project manager can create smaller checkpoints, communicate the revised status promptly and use frequent iterations to reveal delay early. Missing domain knowledge—for example, unfamiliarity with an e-commerce payments process—can be addressed by experienced staff or selectively outsourcing relevant modules.
Personnel shortfall occurs when key people leave or become unavailable. Cross-training and shared technical knowledge reduce dependence on one developer. The lecture uses the specialised payment-gateway module as an example where more than one trained person would help reduce continuity risk.
Business risks: competition and gold plating
A business product can be completed successfully from an engineering viewpoint and still fail commercially if it is uncompetitive. Market research and comparison with other products help identify what users actually value and where meaningful gaps remain.
Gold plating means adding attractive but unnecessary features that the customer has not requested. Extra widgets and reports can consume time, money and attention. Discuss them with the client and assess their costs against benefits before including them.
Risk probability, impact and score
The project manager asks everyone in the team for the worst-case scenario, then creates a risk table; probability P is assigned from 0 to 100%. Impact: 1 negligible, 2 marginal, 3 critical, 4 catastrophic.
Risk = P × I. For schedule slippage with P = 60% = 0.60 and impact = 3, Risk = 1.8. Sort risks in descending order.
Seller Portal risk table: allocate attention
The lecture’s illustrative risk table gives schedule slippage P=60%, I=3; lack of experience P=60%, I=3; personnel shortfall P=40%, I=3; and database scale risk P=20%, I=2. Their scores are respectively 1.8, 1.8, 1.2 and 0.4.
| Risk | P | I | P × I |
|---|---|---|---|
| Schedule slippage | 0.60 | 3 | 1.8 |
| Lack of e-commerce experience | 0.60 | 3 | 1.8 |
| Personnel shortfall | 0.40 | 3 | 1.2 |
| Database cannot scale | 0.20 | 2 | 0.4 |
You cannot anticipate every risk, so focus on the most important ones — e.g. mitigate schedule slippage with milestones and regular meetings with the team and clients, and lack of experience by hiring the right people from within or outside the company.
Quick recall
- A risk is a possible future unfavorable event, not simply a defect already observed.
- Identify the category, mitigation, likelihood and potential impact of each important risk.
- Risk scores prioritize attention; they are not exact measurements of monetary loss.