7.11 Issues List

 < Day Day Up > 



7.11 Issues List

This chapter could have been titled "I Thought I Had Seen Everything When " Each project can invoke the bizarre, although the most prosaic mishaps can be just as disruptive. Once, I failed to receive a crucial overnight delivery because the courier's plane suffered a flat tire before takeoff - the courier chose to wait for the next available 737. This turned "next day" for them into "two day" for me; however, the fact that the cause of a delay defies imagination is not as important as how you react to these delays.

No matter how thorough and successful your preparations were, unanticipated problems will crop up in a frequency proportional to your project's size and complexity. There is only one way to deal with this: develop and maintain an issues log. Exhibit 12 depicts how each issue is assigned an owner and how the status of each issue is monitored until it is cleared.

Exhibit 12: Implementation Issues Log

start example

Issue

Opened

Owner

Status

Status

Due Date

Need additional servers

9/16

Pete S.

9/27

Seeking funding approval

10/15

Vendor contract unsigned

8/21

Joan K.

9/27

In legal department

10/31

end example

If you do not faithfully observe the guidelines given in Exhibit 13, do not use this process because it becomes irrelevant and damages your credibility as a project manager.

Exhibit 13: Issues List Guidelines

start example

  1. Keep the list "net," as shown.

  2. Do not belabor the issue on the chart other than to give it a descriptive title.

  3. Do not track progress in a narrative form.

  4. Review of this list at team meetings should be a recurring agenda item.

  5. Restrict verbal updates to the degree that project impact can be assessed.

  6. Discourage attendees from opining on issues they do not own.

  7. If others should be involved, steer those conversations offline.

  8. Solicit additions each week, and track these as well.

  9. Publish this as part of the meeting minutes.

  10. Delete but archive resolved issues in case the issue is revisited later.

end example

You have to decide how directly involved you need to be in bringing each issue to closure. You do not want to "own" these one-offs unless the logical owner is incapable of addressing a particular issue for some reason. The project office may also take ownership of any issues that cross team boundaries. The most compelling reason for you to assign an issue to yourself is, of course, that it is something so critical to project success or politically volatile, that you would be ill-advised to let anyone else handle it, no matter their level of competence or professionalism. In any case, as project manager, you own the process of identifying and facilitating the closure of all these unique or critical path issues. Let us take a look at the worst-case scenario: a major project milestone is threatened and you must personally see to its timely resolution.

I did a project where users were converted to a new operating environment whereby their desktop personal computers (PCs) were replaced with new laptops using an upgraded operating system. We changed the servers they logged into to access their applications and data. Services such as mainframe printing were also impacted. This project involved 400 users, 24 servers, 70 applications, and 3 data centers.

Several processes, applications, or services failed during the rollout. Some were easily fixed while others went through what I call the "bad car mechanic" scenario. You may be familiar with this; a mechanic replaces part after part, at your cost and inconvenience, in the hope that the malfunction will magically disappear sometime before you rebuild the whole thing. Some of the errors or problems confronting us were these:

  • LAN access to network resources was not thoroughly granted.

  • Applications were installed on the wrong new servers, or installed poorly.

  • New production servers were undersized and required capacity upgrades.

  • Printing services were improperly implemented for some users.

  • New laptops were not consistently configured.

  • Managing complaints was neither proactive nor customer-friendly.

  • The new operating environment confused customers.

  • The customer kept changing the deployment schedule.

There is a way of looking at this and alleging poor planning and management. Although there is some truth to that, the not-uncommon reality of this initiative was somewhat akin to childbirth. Although the results of this process are full of joy and gratification, the final hour is not all that picturesque or serene.

The previous listing documents the root causes of hundreds of complaints recorded during the rollout. Appropriate remediation was not always obvious. Closure rates were worsened because, as is often the case, end users are not the best partners in the fault management process. For instance, when they said they could not print, from a technical perspective there were a half dozen possible error messages, but the user rarely wrote it down so that our team would know where to start. As a result, each new service call was an adventure, at least until a technician realized that User 119's problem was the same as User 12's. Naturally, some technicians had not experienced User 12's problem and had to analyze the problem as though it had not previously been seen.

Needless to say, the team got bogged down in determining which of the three support groups (and their managers) owned the problems, thereby introducing additional frustration and delay. There was also an ugly political backdrop to this, as there was a chance that this would turn into an insoluble disaster and a real public disgrace. To some, avoiding the crown of thorns or trying to put it on someone else's head, therefore, became part of the exercise. Even I started managing individual problem resolution because the responsible parties were overwhelmed. I was not technically qualified to step in like this, but the milestone was beginning to look unreachable, and we were ready to invoke Plan B, which was a rollback to old technology as well as sending out our resumes.

You can expect dozens of e-mails to be generated as situations like these boil over. They become chain e-mails with more senior names being added with each click of the "send" button, and the situation is exacerbated. As this comedy turned into a tragedy, the customer went from a state of confusion, to alarm, to an irascibility bordering on hysteria. That is when the project manager needs to invoke the all-hands triage approach to get this thing back under his or her thumb. Exhibit 14 lists the steps one must take to defuse this type of situation.

Exhibit 14: Triaging Unanticipated Project Disasters

start example

  1. Blow the whistle and yell, "time out!"

  2. Find out who needs to come to the table.

  3. Get everyone together quickly - by phone if the team is dispersed.

  4. Do not make face time a requirement if it introduces delay.

  5. Ask for a summary of the issue(s).

  6. Ask what the resolution should be.

  7. Ask who owns the fix.

  8. Ask what the owner needs to fix the problem or problems.

  9. Ask when completion is likely.

  10. Be supportive; volunteer to make calls or drag in more resources.

end example

In other words, be proactive, especially with the customer. Engage the customer if this could turn ugly, and keep them in the loop. Your being passive gives them the opportunity to drive you, which surely will make matters worse! Follow up methodically. Once people recognize you are on it until the smoke clears, two good things will happen:

  1. The "resolver" will clear the troubles, if for no other reason than to get you off his or her back.

  2. The customer will settle down after observing your commitment to resolve everything ASAP.

In practice, this process is usually invoked just after the ship you are steering hits the iceberg. I am not a sociologist and therefore cannot explain why things get this bad before you have the good sense to blow the whistle and initiate the recommended triage procedure, or something akin to it. One wonders, however, if being slow to get into this mode actually helps because by the time you hit the panic button, everyone else is sufficiently concerned if not scared to guarantee focus and commitment to cleaning things up. Maybe the lesson is that adrenaline is a wonderful thing, and that hysteria cleanses the soul!



 < 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