5.6 Uncovering Project Risk

 < Day Day Up > 



5.6 Uncovering Project Risk

Project risk is defined as the class of events or conditions that can directly impact project success in a negative, if not disastrous, manner. Asking the generic questions listed in Exhibit 3 can expose the vast majority of them.

Exhibit 3: Questions for Uncovering Project Risk

start example

  1. What if the new deliverable does not work as advertised?

  2. What if it works poorly?

  3. What if I cannot deliver everything on Day One?

  4. What if a key technologist or team lead becomes indisposed?

  5. What if a key technologist or team lead is unproductive?

  6. What if we do not have enough skilled resource?

  7. What if we run out of money?

  8. What if a vendor misses a shipment or some other key deliverable?

  9. What if a vendor runs out of money?

  10. What if a key vendor employee leaves the project?

  11. What if a key new product or upgrade does not perform as advertised?

  12. What if we cannot get access to a site whenever we need to?

  13. What if we cannot get access to a process whenever we need to?

  14. What if a dependency does not pan out?

end example

As with this class and the others, the questioning process does not end with a simple response to any of these questions. Having an open if somewhat skeptical mind and following up with common sense is very important. Refer to number nine in Exhibit 3, which ruminates on the potential consequences of a vendor running out of money. It happens. The scenario this question invokes is as follows.

You have assigned certain deliverables to Vendor X, who is small or unknown to you. Truthfully, you cannot guarantee that they have the muscle to hang in there with you should the project prove more complex or time-consuming than originally planned. If Vendor X disappears from the scene, how would you complete those deliverables? If they are proprietary, you face a different set of challenges than if Vendor X is basically providing staff augmentation services to free up your own experts or technicians in that particular information technology (IT) process or discipline.

Having gone this far, if I felt that the risk of this vendor's demise is severe enough, it may cause me to question the benefit in using them at all, or worse yet, wondering why we are using that particular process or technology they are allegedly providing to the project. If you take this approach, you may actually feel responsible for pushing back on the designers or other team members in such a way that the need for the vendor is eliminated, or the intended process is replaced or at least modified to the degree that the risk becomes far more palatable.

Ultimately, risk analysis, like practically every other cognitive duty on your plate, goes to the basic principle of examining assumptions to see how firm your foundations truly are. It is very important that you can envision worst-case scenarios such that you can:

  • Honestly evaluate the deleterious impact on your project

  • Accurately handicap the probability of such risk actually coming to pass

This can be quite gruesome. Few people I know savor the prospect of imagining dire circumstances dispassionately and coolly imagining how to bail themselves out. Unfortunately, I cannot think of any other effective way to do this. I recommend that you sit with the appropriate stakeholders for each potential risk, as outlined in this chapter, and ask them the questions detailed in this section and the next two.



 < Day Day Up > 



Complex IT project management(c) 16 steps to success
Complex IT Project Management: 16 Steps to Success
ISBN: 0849319323
EAN: 2147483647
Year: 2004
Pages: 231
Authors: Peter Schulte

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net