5.4 Identifying Risk

< Day Day Up >

It is therefore critical that you get a buy-in from the potentially impacted party or parties. This must include not just the probability of harm, but also the prognostication of impact. By the way, it is a politically beneficial move for you to induce them to come up with the potential consequences of risk. You do not want to be solely responsible for this risk assessment for two reasons:

You want them fully engaged in this process, preferably in partnership. After all, they should know their world better than you do and, therefore, be in a better position than you to determine the degree of risk associated with any issue you elevate to them. Further, once engaged, they may come up with nuances, or worse, in response to your initial warning.
Should it be determined that an indemnification or remediation plan is appropriate, it will require logistics, resources, and funding your project may lack. The worst position in which you can find yourself is for the potential victim to say, "You are the one creating this mess, so you have to figure out how to fix it, pay for it, and get it done. Call me when you are finished." This condition only compounds the likelihood of damage, so it is one you want to avoid.

The point is made in Chapter 13, which is dedicated to handling customers and beneficiaries, that it is better to take your pain up front, when it is smaller, than to dodge issues until they become unavoidable. This is definitely one of those times. If you get any pushback at all, escalate your thoughts on the situation as far up both food chains (yours and theirs) as you dare and in very clear terms. Let them come back at you quibbling over probability and consequences. In fact, it is great if they do, because you have managed to drag them into the arena where they must negotiate.

However, do not make this a "gotcha" exercise. It is your obligation to educate the potential victim (who could be your own boss, by the way) and make sure they get it. I recently went through a server move planning session with a customer. Regarding the disaster recovery (DR) component of the application platform, there was a strong possibility that when the DR platform was moved to a data center in another state, the DR instance of the database could not be synchronized with the production platform for the better part of a week. It took an hour to walk the user through this, which is why I will not belabor the details The point is that our DR engineer took the time to make sure the customer really understood this scenario. As of this writing, we are waiting for the customer's response regarding the acceptability of this risk, so we do not know what the outcome will be. Still, we are comfortable that our warnings were heard, and are thus confident that whatever happens next, no one will be able to claim ignorance or surprise should that ship run aground.

It is not our decision whether or not the DR data lagging production by nearly a week is acceptable. We do know that the fix would be complex and, therefore, do not want to pursue that until the customer has the opportunity to analyze the risk. Most risks can be obviated by the generous application of money, but how many are worth unconditional exorbitance? As project manager, you definitely want to force the impacted party to make that call. That way, it is easier to ask them to dip into their own pocketbook for any additional costs. It has been my experience that perceived risk is indirectly proportional to the number of dollars the customer is on the hook for to make that threat go away.

In this DR example, the problem was caused not by the move but the manner and means by which the customer managed a several hundred-gigabyte database. In other words, their technology introduced most of the risk associated with the move. A more robust platform would not have created this exposure. As project manager, you must ask why you should take on a beneficiary's problem as your own when you were simply tasked with relocating their platform, not solving the shortcomings of their technology or process.

This is the kind of "scope creep" that frequently emerges from the beneficiary community. Simply put, the project manager exposes potential issues with the legacy environment, and the beneficiary expects the project manager to:

Provide the resources to resolve those issues
In essence, assume financial ownership for preexisting risk

The lesson to be applied here is the recognition that projects often accept these responsibilities long before the breadth, depth, cost, and pain of such a commitment is fully understood, at least by the project manager.

< Day Day Up >