Risk Management

In this chapter, we’ll discuss the risk management process and the type of risks that a TPM may deal with in a technology landscape. We’ll dive into the risk assessment process in greater detail and see how to successfully catalog project and program risks and methods to reduce or remove their impact.

We’ll dive into risk management by covering the following topics:

• Driving clarity in risk assessment
• Managing risks in a technology landscape
• Exploring the differences between a project and a program

Driving clarity in risk assessment

During the introduction to driving clarity in Chapter 4, we discussed the cyclical relationship between project planning and risk assessment. Now, we’ll drive clarity in terms of what risk assessment is and how we continue to manage risk throughout the project’s life cycle.

Risk assessment starts as soon as you have enough information to start assessing, which can be early on in the project. If you start with a project in a domain that you know very well, a single paragraph about the goal of the project may be enough to start analyzing risks. In other cases, where the domain or project itself is too vague, it may take a full requirements document to start analyzing, which is in itself a risk!

Regardless of when the process starts, the steps are the same. Part of the process was outlined in Figure 4.3 in Chapter 4, but the full process has two additional steps that Figure 6.1 outlines:

Figure 6.1...

Managing risks in a technology landscape

There are various aspects of software and hardware development that are common in the industry but less so in other professions. These relate to the development process itself. Let’s take a look at a typical software development life cycle (SDLC) and discuss the common risks that arise at each stage:

Figure 6.2 – SDLC

The SDLC specifies the series of steps or processes involved in software development. This cycle can be adapted to any style of development, including waterfall and agile methodologies. The steps may vary or happen in mini-cycles within the larger cycle, but the steps are still present. Let’s explore each one.

We’ve already talked about the requirements phase in various forms in this book. In general, the focus of the requirements phase is to reduce the overall risk by bringing clarity to the requirements. The clearer the requirements, the less room there will be for...

Exploring the differences between a project and a program

Risk management, as a process, does not vary between a project and a program. Instead of thinking about cross-task risks at the project level, you must think about cross-project risks at the program level. Risk registers, risk logs, and scorecards are utilized in both cases.

As for the tools, each one provides risk management forms and templates at the project level. Tracking risks at the program level may require some workarounds in popular tools. Creating a program project within the program to track these concerns is one such way. Transferring risks down to the projects can also work, though this will include some duplication. Depending on the level of cross-project communication, each project team knowing about every risk that impacts them is a way to reduce instances of risks being missed.

Assessment

When planning the project composition of a program, one aspect to look at is how the project structures can create...

Summary

In this chapter, we learned how to drive clarity in risk management through the steps of the risk assessment process. We discussed the different risk strategies available and how tracking risks is a constant process where the strategy that’s utilized to address risk may change over time. Then, we discussed some key risk categories that show up in the tech industry. We also dove deeper into the Mercury program by driving clarity in terms of the identified risks. Lastly, we looked at how risk management differs in scope from the program to project levels and used the Mercury program to illustrate how a program decision can both remove and create risk based on the project composition of the program.

In Chapter 7, we’ll close our deep dive into key management areas by focusing on stakeholder management. We’ll learn how to drive clarity with stakeholders through various stakeholder processes such as communication plans and status reporting. We’ll look...