MGT 646 Module 6 Risk Assessment Example

The Risks We Would Rather Not Talk About: A Risk Register and Response Plan for SmartSync

Student Name

Master of Business Administration, Aspen University

MGT 646: Project Management Organizational Framework

Instructor Name

Month Day, Year

The Risks We Would Rather Not Talk About: A Risk Register and Response Plan for SmartSync

SmartSync now has a scope, a schedule with a six-week buffer and a budget with a $1.0 million contingency. Each was built on assumptions that might fail. This module identifies what could go wrong, and what could go unexpectedly well, scores those possibilities and plans what to do about them. Probabilities and costs are estimates made by the team for this case.

Why Risk Management Matters Here

Raz et al. (2002) surveyed more than a hundred projects in Israel and examined how widely risk management practices were used and whether they related to success. They found that formal practices such as risk identification, analysis and response planning were not widely used. Projects that did apply them tended to do better on schedule and budget, and the association was strongest for projects with high technological uncertainty. SmartSync's on-device speech recognition, new to NexTech, places it in that category. Formal risk work is worth its cost here even if it would be overhead on a routine product refresh.

Looking Across Dimensions

Wallace et al. (2004) surveyed software project managers and identified six dimensions of risk: the team, the organizational environment, requirements, planning and control, users and complexity. They found that social subsystem risks, such as team and organizational problems, affected technical risks, and that together these influenced both product and process performance. The lesson is to look beyond technology. The SmartSync team ran its risk workshop through each dimension in turn, which added risks a purely technical review would have missed, such as engineers being reassigned and the sponsor's attention shifting to a new acquisition. The user dimension mattered too: beta households might find setup confusing, and a product that fails its first five minutes in a home rarely gets a second chance, so setup testing was added to every sprint from month six.

The Risk Register

Responses and Expected Cost

Each risk's expected cost is its probability multiplied by its cost impact after the planned response. The speech accuracy risk carries the largest, about $280,000, followed by tooling at about $210,000 and certification at about $160,000, a figure that would be higher without the pre-scans that cut its likelihood to one in five. The twelve risks together carry an expected cost of about $860,000, inside the $1.0 million contingency. If the speech mitigation fails, though, the contingency would be used up quickly, which is why the first-ten-week chip test in Module 1 matters so much.

How Risks Were Scored

Probabilities were set by the risk owner and challenged in the workshop, using five bands from very unlikely, under 10%, to very likely, over 70%, with a point figure chosen inside the band. Cost impacts came from the budget's own figures, such as the price of a tooling revision or a second certification round. Schedule impacts were judged against the six-week buffer: any risk that could use more than half the buffer on its own was marked for monthly review whatever its probability. Scoring this way is still judgment, but stating the bands and sources lets others challenge the numbers.

Opportunities

Risk includes upside. Two opportunities appear in the register. The chip supplier has hinted at a newer, faster part that could raise accuracy and simplify compression; the response is to exploit it by testing samples alongside the current chip. A thermostat partner has offered joint marketing at launch, which the sales director will pursue to raise first-year sales. Opportunities get owners and actions just as threats do.

The Risks No One Raises

Kutsch and Hall (2010) studied project managers in information technology and found that they sometimes deliberately ignored risks rather than overlooking them. Some risks were set aside as outside the manager's remit, some were treated as taboo because naming them would embarrass senior people or weaken the case for the project, and some were judged too uncertain to act on. Deliberate ignorance left those risks unmanaged. SmartSync has two such risks. The sponsor may lose interest if the company's new acquisition demands attention, and the board may cut the budget if quarterly results disappoint. The project manager has added both to the register, with the response of short, regular sponsor briefings and a list of scope that could be deferred if the budget is cut.

Keeping the Register Alive

The register is reviewed at every sprint review and every hardware gate. Owners report on triggers, such as accuracy test results or tool maker feedback, and newly spotted risks join the register at the next review. Risks that pass their window, such as certification once the certificate is granted, are closed and their share of contingency released back to the sponsor, so the reserve shrinks as uncertainty does. Each closed risk gets a line on what happened and whether the response worked, building the history the next NexTech project can use when it scores its own risks. The project manager also reports the trend in total expected cost each month; a rising trend late in the project is an early sign that the contingency may not last to launch.

Conclusion

Raz, Shenhar and Dvir justify formal risk work on a high-uncertainty product, Wallace, Keil and Rai widen the search across six dimensions and Kutsch and Hall prompt the team to name uncomfortable risks. The register and expected value check show a contingency that is adequate but thin.

References

Kutsch, E., & Hall, M. (2010). Deliberate ignorance in project risk management. International Journal of Project Management, 28(3), 245-255. https://doi.org/10.1016/j.ijproman.2009.05.003

Raz, T., Shenhar, A. J., & Dvir, D. (2002). Risk management, project success, and technological uncertainty. R&D Management, 32(2), 101-109. https://doi.org/10.1111/1467-9310.00243

Wallace, L., Keil, M., & Rai, A. (2004). How software project risk affects project performance: An investigation of the dimensions of risk and an exploratory model. Decision Sciences, 35(2), 289-321. https://doi.org/10.1111/j.00117315.2004.02059.x