3.7 Review Risk

 < Day Day Up > 



3.7 Review Risk

Deliverables in any project have some risk. Chapter 5 is dedicated to the topic, but it is appropriate to take a peek at it here from a technology planning perspective. You should look for potential leaks and foul odors in a few places:

  • What happens if this technology cannot deliver the requirement(s)?

  • What are the chances that this works in the lab but does not scale to the 20,000 targeted beneficiaries?

  • How can we validate that this will work in our real world?

You might find yourself getting booed off the stage, but you are not doing your job if you do not press the technologists to provide their own thoughts on these three simple questions. Most are honest and professional, but your job is to ensure thoroughness. The key is not being a topical expert, but dedicating yourself to sniffing out risk and inspecting for a good plan that will test for, and resolve, as many errors as possible. Because you are staking your own reputation on project output, this is not the time to give technologists the benefit of the doubt because you do not know their field, or you like them, or you cannot be bothered.

As for mitigation, once potential risk is identified, the task at hand is crafting good Plan Bs. [1] This is a relatively simple thinking exercise. Take a minute to review the server migration plan we presented earlier. If you notice how it is crafted, you can see that risk mitigation is built right into the test and implementation plan. Exhibit 9 gives an appropriate summation.

Exhibit 9: Plan B for Server Farm Migration and Relocation

start example

Risk

Plan B

The re-architected database or application does not work.

It is thoroughly tested beforehand with user's legacy LAN/desktop.

The users' new LAN/desktop environment proves incompatible with the legacy application architecture.

We test well in advance of migration to the new LAN/desktop so any issues can be identified and repaired.

The new LAN/desktop environment does not work with the re-architected application at the new site.

Validate legacy LAN/desktop environment works with re-architected servers, then test new environment.

end example

In summary, the idea is to know where to look for risk, understand the impact of any significant risk, and have a plan ready to overcome or avoid those undesired consequences. In this case, our risk strategy assumed the worst-case scenario - that the re-architected application would not work on the new desktop in the new site on the date set by business cycles and move schedules. We recognized the need for a multiple fallback strategy so that we can run the old application from the new site on the new desktop in the event that target state, running the new application on the new desktop from the new site, was delayed. If you review the last table, you will find those steps are documented.

[1]See Chapter 5 for more detail on risk analysis and mitigation planning.



 < 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