Risk Management on programs

Tolerate uncertainty and live with it, understand complexity, ambiguity and live with it, manage all these tensions about what can happen is the main goal of risk management.

Projects managing risks in an isolated way is a big risk for the organizations. By this reason the use of a clear risk management framework at program or portfolio level is used.

Risk management strategy, should reflect the organization’s risk policies and processes. In this way the program will inherit same principles and risk appetite of the organization. It also facilitates the organization to define the limits of delegation of authority they want to delegate.

The definition of tolerance thresholds is key as it translate risk appetite into a guideline that steers program and project behavior. Thresholds define the exposure to risks on one level that, if exceeded, requires escalation and reaction from level above.

The uncertainty associated to a risk is expressed within the relationship of the likelihood and the impact it has (preferably expressed in $$). In a program the complexity increases as the combination of risks of different projects can generate a complicated net of exposure, which typically is represented on a risk matrix diagram. Sometimes what is negative for a project is an opportunity for other.

The use of healthy checks during the definition of the programs or the attendance of a bid is key to review the business case or the opportunity from risk management perspective. They oblige you to think about key questions you should think about. I find them useful, not as a controlling tool.

Project aggregation; sometimes a project under execution is added to a program. This requires to the program team to asses the impact of this addition at risk level, review the business case and review the budget.

Risk-Matrix

When you want to review things you cannot understand

We are involved in a project with a weird set of requirements: customer insist on approving all technical documents involved in the project.

Ok, no problem, we have adapted the project plan to deliver them and allow them to check it. If you are able to check it, we have not problem to adopt this approach.

Functional analysis and technical analysis has not been a problem, they were able to review it, to understand it and to provide some feedback about the functionality. Everything approved and we go ahead with next phase: design.

Last week we delivered first 2 design documents, and they still are not approved. Why not? Let’s review some background,

The client teams are composed by a project manager that is not specialized in .NET activities and the end users core team are chemicals that in the past used to develop applications in Visual Basic (this is the reason to be involved in the core team).

I was waiting this point, the project manager was so surprised about this event, but I was waiting for it.

My point of view seeing the people who compose the project team from the customer side is that they have to use the technical and the functional requirements as the maps to go through the application development. It’s supposed they delegate this development to an external company because they don’t need to have this knowledge in their staff.

The good thing was that the RACI matrix was done in the planning phase, so now is easy to identify who should do this. Let’s see how the communications go,

(Astorga, León, Spain)