Identify the program risks and figure out ways to mitigate the risks. Learn to recognise symptoms that a risk scenario may be triggered.
Picture source: cumbriacrack.com
A program risk is an uncertain event or condition that, if it occurs has a (normally) negative effect on at least one program objective. Risk Management is the systematic process by which you plan for identifying, analysing, monitoring and responding to program risks. Program risk management helps you make informed decisions regarding alternative approaches and the relative risks of each approach so that you increase the likelihood of success. As a result you can minimise adverse impacts to scope, cost and schedule and quality and maximize opportunities to achieve the program objectives with lower cost, shorter schedules, enhanced scope and higher quality.
Ensure that you are clear on what is a risk to the whole program as opposed what is a risk to a component project. There is no point in your flapping around and wasting a lot of time trying to manage a risk that needs to be managed by a project manager (unless of course, the project manager comes to you for help). And how would you judge whether a risk is a program risk or a project risk?
- Is the risk affecting RoI or benefits delivery?
- Is it affecting organizational strategy delivery?
- Is it a risk based on market / environmental factors?
- Is it affecting project output integration with system?
- Is the risk affecting financial performance?
If the answer to some of these questions is yes, you are probably dealing with a program risk and you should be up in arms against it.
First of all, you need to identify the risks. An analysis of grey areas in requirements, green field functions / technology, performance targets and constraints is the first step to identifying risks. Analysis of initial scope, high level schedule, critical resources; identifying assumptions and their impact; analysis of high level dependencies; assessment of organization capability versus program demands: these are all the things you have to do if you want to identify critical risks lurking behind the corners. You will need to rely on organization experience, risk repository, expert opinion etc. to identify risks.
Once you identify the risk, you need to work out the probability of it happening. You can use a tool like the one below to assess what you need to do vis a vis each risk. Slot each risk you into one of the quadrants below and this will help you plan your response to the risks.
How do you respond to the risks? The normal way is to accept the risk and plan for contingent action. You accept the consequences of the risk if it occurs but have some back-up plans to salvage the situation. Another is to mitigate the risk, that is, reduce risk probability or impact or both. You can also accept the risk by building a work-around. That is, find a way of achieving the same benefit by a method that may not be as efficient as the one that triggers the risk. One way of course, is to avoid (remove) the risk by foregoing the associated benefit.
One of the key inputs in determining risk responses is stakeholder risk appetite and normally a combination of the above approaches is accepted.
As an example if you are faced with a risk that the performance of a mission-critical system you are developing for delivery on a particular piece of hardware may not be satisfactory on the target hardware resulting in product failure. This is a Program Risk as it will affect RoI delivery as well as benefits delivery.
Some possible risk responses are
- Conduct “proof of concept” on multiple low cost platforms and choose the one that offers best price/performance (get the h/w developed by more than one organization)
- Get hardware provider to commit to feature support (may result in higher cost from provider)
- Get hardware provider to commit to query turnaround / issue resolution time (may result in higher cost from provider)
- Decide on a minimal required feature set and deliver the first release; provide for additional effort, schedule & cost for subsequent releases when you address the next level of features (may be on time and material basis)
- If similar work has been done in the past with the target hardware or if the new release is a small delta, the risk may be accepted perhaps with some buffer for R&D
Exercise: Create a linkage matrix between program and project risks in your program
7 Tips for Effective Program Management (A practitioner’s approach)
Tip 1 – All the world’s a stage – Understand your role
Tip 2 – Don’t fail to see the forest for the trees – Understand the big picture
Tip 3 – They hold all the stakes – Map them out
Tip 4 – Use support structures and technologies to your advantage
Tip 6 – Dot your I’s and cross your T’s – Understand the program commercials and contracts clearly
2 Responses