I used to dread risk management. What I learned time and time before came down to 3 basic risks
- not enough support from the top
- not enough money
- not enough people who know how to do the job properly
There is some truth to it although it took me a long time to understand that’s only one small aspect. And what’s even more important discovering the other views on risks can mitigate those basic risks dramatically.
Let’s look at those views in more detail. You’ll not be surprised if I pick up on the status quo again. The status quo can teach you a lot of things. First of all you’ll know who are the key players. These guys tell you their view of the lay of the land.
- missing functionality that is of key value to individual stake holders
Key functionality is a synonym that includes items like software features if you change an application to process benefits if you introduce a new way of doing things. It describes the practical elements of the status quo. Assumptions are easily made and can lead to missing certain elements. Challenge assumptions and confirm before it is set in stone.
- missing a stakeholder who has significant investment in the status quo
You may think you know who to talk to and who to invite for the discovery talks. However, you probably are an outsider and more likely you have an outside – in perspective. That is you see the shortcomings of the status quo before you see the benefits. Hence it is quite possible that you talk more to people who have less investment in the status quo and see a higher value in a change. Your communication strategy must be geared the other way round.
- adherence to safety, security and compliance regulation
Independent what change you are initiating there are rules and regulations that apply. I just recently made the mistake and took the word from a key stakeholder, “There are no changes to the security.”. Well, there were changes to regulations because we were moving a system where the internal security features stayed the same but external compliance regulations had changed. Challenging then the core assumption “security doesn’t change” showed additional aspects that needed to addressed.
- change of the priority driving the change
Most (if not all) changes have a sponsor. That sponsor has either an inherent interest in the change or has been convinced (ROI, Business case) it being of business value. The sponsor owns what priority drives the change. Timing = this has to be done before xyz. The wedding is on Sunday so everything has to be in place by then. Quality = this has to be perfect before we launch. The space shuttle launch is planned for a certain date. If a complication arises that drives a new launch date. Budget = this is the money we are prepared to spend on it. “The issue can be fixed by Monday morning for an extra 10%.” If that is outside the agreed budget, then the fix has to be done using normal working hours and the project may be delayed. While you are responsible for a change project be prepared that this core priority may change on you. Be also prepared to explain the impact of such a subtle change to the sponsor and other stake holders.
- information management during the project
Often I hear people complaining that people they want in the project team are unavailable or overloaded with work. Sometimes people leave a project team for different reasons. The core challenge in my opinion is managing the information that is gathered and created throughout the project effectively. Knowledgeable people can be resourced either internally or as contractors. The challenge is more how the information is kept and stored and communicated.
I believe by addressing risks in such a way that they mean something specific to the different stakeholders they can be mitigated much easier compared to the 3 ‘basic’ risks.
Looking forward to your comments!