7.4 Raising a Project Jeopardy
|
| < Day Day Up > |
|
7.4 Raising a Project "Jeopardy"
For some reason, when I think of project jeopardy, I am reminded of the kid who cried "wolf!" once too often. I am not sure why that is because, if anything, project jeopardy is called far too infrequently. Two possible reasons can be cited. First, some project managers may not actually recognize the need to cry for help. One of the reasons I wrote this book comes from having watched many project managers, myself included, struggle to understand our ever-changing projects. Big projects in particular can become overwhelming, confusing, or both. It is definitely possible that you are wandering around in a fog and do not know how close to the cliff's edge you have come; and, as a result, you fail to yell "watch out!" until you are on your way down.
The other interesting spin on this topic is the natural tendency of people to avoid the appearance of ineffectiveness or incompetence. To them, issuing a project jeopardy is tantamount to admitting failure, a tactic few project managers adopt as a career-advancing strategy. Project jeopardy, however, does occur, often through no fault of the project manager, or perhaps anyone else, for that matter. Putting aside self-promotion for a moment, let us examine this business of issuing a project jeopardy and then talk about how it should be done.
Section 7.2 laid the groundwork for jeopardy. The process is pretty much the same; however, in the nonjeopardy situations, I recommended keeping negative pronouncements low key and nonvolatile. Also implied was a reasoned approach that included a dialog during which you can steer consensus toward your preferred remedy.
The trick with jeopardies is recognizing that the issue before you is not something you can take a reasoned approach with and clear up with a few meetings pretty soon. It is also possible that the cause of the jeopardy is not all that dramatic, as the upcoming example will illustrate. What causes you to click on the hot end of the RAG (Red Amber Green statusing methodology) spectrum is the discovery of some event or condition that you and your team conclude:
-
Will be a showstopper
-
That someone important better be forewarned and engaged to push buttons you would not dare touch in your most brazen moments
Jeopardy arises from a variety of mostly mundane sources. Late shipments, nonperforming vendors, weather, faulty technology, and regulatory or financial issues can individually, or in sinister combination, puncture your life raft. Although you want to anticipate them and arm yourself with the right kind of Plan B insurance policies, when the truck is careening toward the ditch, those Plan Bs can seem childishly incapable of averting disaster.
The second of our four-problem diagnostic questions was: "What is the worst-case scenario in terms of impact on the project?" I once had a network engineer respond to this by saying, "We all die a slow and horrible death!" He was speaking professionally of course, but that was his way of saying "Pete, you better go do something fast!" Luckily, this warning surfaced a few days early. The problem had to do with a squabble between a supplier, the receiving department in the data center, and our purchasing department regarding the current location of several gigabytes of random-access memory (RAM). The memory had to be installed in the new firewalls before we could load the software that would allow us to reroute the network to the new demilitarized zone (DMZ) and triple throughput before the year-end freeze. If we were prematurely halted by the freeze, the network cutover would be delayed by 2 months. Missing this milestone would have been politically devastating because we were dealing with an impatient, if not hostile, customer.
I was aware of the dispute regarding the missing RAM. I had previously given my manager a heads up on this weeks-long dispute, and I tried to resolve the problem through all means at my disposal short of making the 100-mile drive myself to hunt down those pesky little memory chips. In fact, I had requested the authority to buy replacement memory as a contingency but was shot down, twice, because year-end cost cutting was in full flower.
In other words, this was a mess that had been going on for a while. When the engineering manager called me, he said, "Mr. Boss Man, if I do not have the memory by Friday, I cannot load the software this weekend, which is my last chance this year." Honesty compels me to report that I had lost track of the drop-dead date because I was consumed with other project issues. Lucky for me, I had long since escalated the issue and could prove that all attempts at remedy had hit various bureaucratic roadblocks. So, at least I was not exposed from that perspective. It is important that you have laid the groundwork for a jeopardy situation with prior status notes and escalations, preferably well in advance of issuing that call to battle stations. Given the way my previous attempts at fixing this problem had been rebuffed, I almost enjoyed issuing the jeopardy displayed in Exhibit 3 - all the way up to the CIO as I recall.
Exhibit 3: Extranet Project Jeopardy
 |
| There has been an ongoing problem regarding a mis-shipment of RAM memory required to complete the configuration of the nineteen firewall devices. The Project Office and Purchasing have been unable to resolve the dispute among the vendor, the shipper, and the data center receiving department. The signature on the receiving document is indecipherable, and there is no log indicating the items in question were received. Both the vendor and the carrier claim the product was definitely shipped and received 6 weeks ago. A project jeopardy is being issued. If the correct amount and type of RAM memory is not installed by Friday, the cutover to the new extranet connection will have to be postponed until after the year-end network freeze (i.e., the next maintenance window available after January 15, 200x). I have validated with the vendor that if they receive a purchase order (PO) by end of business day tomorrow to replace the disputed memory, they will deliver those items to the data center no later than noon on Thursday. That would give us adequate time to meet the schedule without undue rush. The vendor has agreed to sell the memory at cost, thereby saving the firm approximately $3,500. The PO would have to be in the amount of $21,041, tax included. Unfortunately, no alternative solutions are available to us. The software will not function properly without the memory. Please advise whether to proceed with the reprocurement process or reschedule the network cutover for January. Thanks. |
|
Exhibit 4 outlines the few differences between this document and the escalation script in Exhibit 2.
Exhibit 4: Jeopardy Document Rules
|
|
|
In other words, the point of issuing a project jeopardy is to tell the senior-level managers:
-
What the problem is
-
How you propose to solve it
-
The most probable consequences of inaction
Be sure to include dates, times, and a brief history in case they wonder what led to this demand for a quick decision on their part. Do not just say, "help me!" or "duck!" Be sure they understand what you are asking them to do. As long as you do this with a modicum of professionalism and literacy, you are likely to get what you need, particularly if you have credibility within the organization.
In case you are wondering how the firewall memory jeopardy turned out, about an hour after my friend in procurement faxed a purchase requisition for the replacement memory to the vendor, our engineering manager notified us from the data center that one of his guys found the missing memory in some boxes from a different vendor on a cart headed to the dumpster. The way I look at it, we made the deadline and saved the company $21,041 - too bad about those extra meetings, though.
|
| < Day Day Up > |
|
EAN: 2147483647
Pages: 231