5.9 What to do with These Questions

< Day Day Up >

I do not tout these lists as all-inclusive. Furthermore, I am confident you can think of additional or improved inquiries. That is fine with me. Some questions might not apply to your project, whereas others may be used several times when you have multiple deliverables, for instance, or have unconnected beneficiary groups to deal with. It should also be mentioned that these questions are generic, meaning they cover areas of concern that require specificity based on the project at hand. Also, an exhibit in Chapter 7 documents most of the common contributors to date slippage, which in turn is a key, if generic, risk. You might want to refer to that list before heading off on your risk scavenger hunt.

I need to make additional comments in this space. In the wedding reception scenario, everything was covered - everything except for the most important piece. This piece is the articulation of risk and why it must be avoided, which in this case is the fact that it is simply unacceptable to expose the reception to inclement weather. Many items need to be protected: outfits, hairdos, the wedding cake, table settings, and the band or DJ's expensive electronics. As you look for risk in IT projects, you need to understand how to imagine unacceptable scenarios, and work backward to the events that precipitate them, or at least serve as warning signs. With weddings, it is simple. A soaked bride, or Aunt Millie slipping on a wet dance floor and cracking her hip, are clearly unacceptable conditions that are easily prevented by indemnifying the venue, including its infrastructure and denizens, against rain, standing puddles, slippery grass, and spattering mud.

The best way to produce similar project analyses is to trace the project's critical path, or review the implementation strategy you built after applying the thoughts from the previous chapter. The critical path consists of a half dozen or so milestones with fixed dates. Once you identify the key deliverables that contribute to each milestone, you can examine each of these for potential "breaking points."

Looking at dependencies is another great way to uncover risk. In fact, it is my personal favorite. I have been on many projects where a risk was based on something beyond our control happening, or not happening, in a specific way, and by a crucial date. In one of my more complex projects, we built a new corporate campus. The company used two well-known operating systems for local area network (LAN)-based computing. The forward-looking engineers on our team wanted to eliminate the use of one manufacturer's legacy protocol in the new site. This LAN communications protocol was quite the thing in its day but was in the process of being replaced by Transmission Control Protocol/Internet Protocol (TCP/IP) in the normal course of product evolution. The problem was that many of the older applications in the environment resided on servers that used the older protocol. The risk was if we blocked the older protocol from entering the new site across the wide area network (WAN), users moving in would be unable to log into applications resident on the older-protocol servers at other sites. I should mention that this organization had many thousands of servers, many, if not most, of which could reasonably be assumed to still use this older protocol.

Therefore, I worried about disgruntled, unproductive users in our new site (i.e., those users at our new site wishing to log into one of these older servers found elsewhere in this corporation's far-flung network). Engineering informed me that there was another project afoot to update all servers to the IP version, and that this should be accomplished before our new site opened, so this protocol issue would be moot.

I said, "Great!" to their faces, but privately was not so reassured, because, quite frankly, I did not believe that this server upgrade project could possibly be completed worldwide before we opened our new site. My view of the risk was that an executive visiting our site would want to log into some legacy server in Geneva or Sydney and be unsuccessful. This is the very type of client you would not choose to disappoint. So, we took the coward's way out and allowed the old protocol in our new site. We received no complaints related to this protocol issue, so I was happy. Further, our conservatism was vindicated because as of this writing, some 2 years later, the protocol upgrade project had long since been cancelled, well short of completion.

As dependency risks go, this is not the most exciting story, but it is relevant when you consider how the issue came up in the first place. During the project design phase, we were having a technology review with the engineers. I mentioned having read somewhere that they intended to "turn off," or filter out, the old protocol at our new site. Having long since lost my aversion to sounding ignorant, I asked what the benefit was in doing this. The answer was that this legacy protocol tied up bandwidth with lots of network chatter, and the manufacturer was phasing it out.

That sounded good. Still, I asked what to me is an obvious project management question. "Is there any downside to keeping the old protocol out of the site?"

"Well," I was told, "Anyone at the new site trying to access a server using the legacy protocol somewhere else in the corporate world would be unable to do so. Unless, of course, they called the Help Desk, and a change control was issued for the router filter tables, a process that normally takes 3 to 5 days to complete."

I may be technically dense, but somehow this solution did not strike me as being wholly aligned with the customer service model, particularly when contemplating the aforementioned visiting executive needing access to a legacy protocol box on the far side of the globe.

< Day Day Up >