5.15 Pulling Your Plan B Together

 < Day Day Up > 



5.15 Pulling Your Plan B Together

It appears that now we have agreed on an action plan to address a risk that should be avoided at all costs or would, at the very least, need some deodorant. We have agreed under what circumstances we would bring that action plan to life, which implies a scenario with a date associated with it. Now we have to complete the plan. What is left, you ask? Why, the four worst pieces, of course, which are:

  1. Who is going to write the plan?

  2. What is the decision point, or trigger, that invokes Plan B?

  3. Who is going to do what if the plan is invoked?

  4. On whose nickel would this get done?

Funny, when you put it like that, it sounds like any other planning opportunity in the project world. That is what Chapter 6 is all about, in conjunction with Chapter 4, of course, regarding the crafting of the anecdotal implementation strategy prior to throwing names and dates at the wall. I do not want to steal my own thunder, but contingency planning has a funny little twist that deserves one last look.

As a carpenter, if I were asked to build a structure to provide weather-proofing and security for storing materials to be used at a construction site, obviously I would not build the Taj Mahal. Why spend the money and time making it bulletproof for the ages, right? Still, I would probably find its complexity would be uplifted by building codes, insurance and safety considerations, union work rules, site-specific issues (i.e., space and convenience), and so on.

Contingencies in the IT world are not much different. Presumably, whatever you are planning to do, even on a "maybe basis," will be shaped by your real world. Data will be passed across the corporate network, people whose safety is proscribed by corporate liabilities will be temporarily housed, vendors with existing performance clauses will be engaged, and other resources will have to be fed and watered as normal. In other words, from a planning perspective, you are not likely to be free from any of the constraints you would face were your contingency plan the real thing. That increases costs and timeframes, possibly well beyond the "for temporary use only" paradigm originally envisioned. There may not be adequate connectivity, power, or rack space in the computer room for those five extra servers. It may be Thanksgiving, and changes to the network are tough to get approval for because of that traditional year-end freeze; and on and on it goes.

The bottom line is that you will not be able to put off any detailed planning, or hide the potential need to invoke a Plan B from the managers and bean counters who will add many cycles to the process once you turn up the lights. Let us close this thing with an experience from my own recent past.



 < 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