3.12 Proceed with Rollout, Invoking Your Plan Bs as Required

< Day Day Up >

Managing project implementation is the subject of Chapter 7, so we will not spend much time on it here other than to close the loop on validating your technologies. The original premise of this chapter was that, as project manager, you are the sole individual tasked with worrying about everything coming together because your team leads are "smokestacked" with their individual enterprises. Keep in mind that everything may not come together. Delays and their causes are explored later in this book, too.

You do need to begin preparing for that eventuality, however, and think about how to manage around that - now. Some deliverables are truly stand-alone, so if they are late or prove to be unwieldy, you should understand what position you may be forced to take. For example, our target state chart earlier in this chapter suggested the potential rollout delay of certain deliverables. The only one so noted was wireless LAN. When I researched that technology, I could see two major problems with the maturity level of the product. The first was that the 400 kilobytes-per-second throughput compared very poorly with the 100 megabyte house network users could access in cubicles, offices, and conference rooms.

The other drawback was security. At the time, wireless LANs were not that hard to hack into, even from cars on the street, using off-the-shelf hardware and software. The nature of this client's business made that exposure unacceptable. As a result of these deficiencies, wireless LAN moved from Day Two to Day One. That was one of the few noncontroversial calls we made on this project because there was not much pent-up demand for the service anyway. Still, just to cover ourselves, we had the contractor install antenna cabling throughout the site so the infrastructure was in place. Whether wireless LAN gets turned up in this particular location remains to be seen.

You may feel obligated to make other technology adjustments as well. If, unlike the wireless example, your problematic technology remains compelling even though its rollout is not shaping up, you may need to dilute its intended rollout or slow it down. You may need to beef it up, such as adding servers if capacity or speed is not scaling as you had been led to believe that it would. Other tactics can be invoked as well, depending on the technology and the problems you are having with it. I must say, however, that none of these potential adjustments should come as a surprise. The preemptive testing strategy outlined in this chapter should be rigorous enough to suggest the probability of disappointing performance. If that is the case, and a quick fix does not appear likely, you must initiate damage control with stakeholders. Whether it is to dumb down expectations, or to perform other undesirable political acts, keep in mind that bad news is much better received early than late. There is no applicable "just in time" paradigm associated with project management, especially when it comes to blowing the whistle on unrealistic or uninformed expectations.

< Day Day Up >