Section 11.5. Resolving Common Project Problems

11.5. Resolving Common Project Problems

In this section of the chapter, we're going to discuss common project problems and provide ideas for addressing these problems. Obviously, we can't cover every possible scenario, but we will cover some of the common problems. By recognizing common problems, you may be able to head them off at the pass. As you continue to hone your IT project management skills, you will probably intuitively avoid these more common mistakes. As part of your lessons learned activities in your IT project, you may want to add to this list and keep it handy as you manage future IT projects. We can't always avoid mistakes, but at least we can avoid making the same mistakes over and over again.

11.5.1. Problems with Scope

As you know, scope is the total amount of work to be accomplished on the project, so defining scope is fundamental to the project work and to the project's success. Problems with scope come in two primary flavors: problems with scope definition and problems with scope management.

11.5.1.1. Vague Scope Definition

At the outset of a project, during the definition stage, it's possible that not enough detail is yet known to clearly define the scope of the project. During the definition stage, you should strive to create as much detail about scope as possible. The scope document or definition should clearly describe the circumference of the circle of project work, while not necessarily providing great detail. It should answer the question, "How will we know when we've finished our work?" or to use the travel analogy, "How will we know when we get there?"

Possible Solutions: Add or develop specific, measurable criteria to the scope document if it is vague. Many organizations call these SMART goals - specific, measurable, attainable, realistic, and time-based (some people use tangible as the last element). Instead of "Improve system uptime" as a scope statement, quantify that by putting some numbers in to it. "System uptime will be 99.95% overall uptime with no more than 30 minutes per week for unscheduled downtime." Even if you later discover the goal is not possible, you have drawn a line in the sand and everyone knows what the project is all about. This detail allows you to push back on any proposed changes that might increase scope. If you have a sound change management process defined (and in place) for your project, you can better manage proposed changes to the project that will implement scope.

11.5.1.2. Scope Not Feasible

Sometimes despite our best efforts, we discover, as we're midway through the project, that the scope is just not feasible. Often projects start out sounding great, but once we get into the functional or technical requirements phase, things start looking bleak. Projects that include "discovery" work are most susceptible to this problem, though all projects by their very nature are vulnerable to this risk.

Possible Solutions: Be sure to clearly define project specifications and proposed approach. At the moment the project's scope (deliverables) are deemed not feasible, you should notify your project sponsor. If there is a business need driving this project, you may need to go back to the drawing board. If not, you may want to recommend this project be cancelled. There is no sense in chasing after a result that is not possible or feasible. If you recall from earlier discussions, part of your evaluation of the project at each step should be to ask whether the project (or any element) is logical, feasible, desirable, and affordable. If you've been asking this all along, you're less likely to wind up in this situation. However, if you cancel a project that is no longer feasible, you can at least be viewed as part of the solution instead of being viewed as the part of the problem.

11.5.1.3. Errors in Approach

Sometimes despite our best project planning, we select the wrong approach. The scope may be well defined, but how we choose to deliver on that scope may be wrong. Often the wrong approach is embedded in the technical specifications, derived from the functional specifications. If you define a specific set of functionality and then choose the wrong method of providing that functionality, your project can get off track quickly. If your technical specifications assumed or specified a Windows-based solution but other components only work on a UNIX platform, you have an error in the approach.

Possible solutions: To the degree possible, look at functional and technical requirements closely to ensure you don't have a disconnect. If an error in the approach is discovered after project work commences, you have two choices. One is to stop project work and go back through your planning stages. This can be timeconsuming and politically perilous, but can ultimately yield a more satisfactory result. A second option is to sit down and figure out how to address the problem at this juncture through change control methods. Ideally, your schedule and budget reserves should help cover the additional time or money required, but that may leave the rest of your project work exposed to time and cost risks. Whatever you do, sit down with your project sponsor immediately to address this issue before it gets out of hand, becomes a political minefield, or blows up in your (or the project sponsor's) face. Getting out in front of this kind of issue is the best approach because regardless of how painful it is now, it will only hurt worse as time goes on.

11.5.1.4. Scope Creep

We've discussed the dangers of scope creep repeatedly throughout this book. When an IT project scope keeps expanding, it makes it virtually impossible to meet any measure of success. That said, don't be afraid of change. Sometimes changes are innovative and ultimately reduce the time or cost of a project or increase the quality or perception of the project. Large changes are those that are most dangerous and should be brought through your formal change management process.

Possible solutions: First, educate everyone involved with the project about the dangers of scope creep. Gain agreement from the IT project team to use the change management process to manage scope changes. Avoid making changes to scope without fully analyzing the change and assessing it in terms of its impact on the project as well as on the time, cost, and quality of the project. Push back on your project sponsor if he or she insists on changes to scope once project work has begun. If change is required, be sure to let everyone (including executives and the project sponsor) know how the change impacts the project.

11.5.2. Problems with Quality

Any problem with quality can be called a bug or defect. The term bug is used more often in software projects and when a machine running questionable code acts strange, it's often said to be "acting buggy." We'll use the terms bug, error, or defect interchangeably in this section. For more on software bug tracking and management techniques, you can download the bug tracking template from the Syngress website.

In some projects, quality metrics are very clear-cut. In other projects, quality tends to be more subjective and your role is to be the arbitrator or final authority on all issues related to the project. This means making decisions in a timely fashion, having clear policies, and sticking to them. There are several common problems you may run into regarding project quality that we'll discuss in this section along with possible solutions.

11.5.2.1. Initial Results Do Not Meet Quality Standards

If the first project deliverables (or early versions of them) do not meet quality standards, you have a problem. Quality defects at this point are signs of bigger problems. The good news is that problems you discover at this point are easier and less expensive to fix now than later.

Possible solutions: Regardless of the direction you take, you must address the quality issue immediately. In some cases that might mean halting project work until the source of the problem can be discovered and remedied. The logical starting point for your inquiry should be at the taskdid the person performing the work understand what needed to be done and did he or she have the skills, tools, and resources to accomplish that work? Was unit testing performed and were the results acceptable? If a team member is submitting sub-standard work, look more closely at that person. Task owners (and those doing the work) are responsible for submitting work that meets scope and quality standards. Unit testing should find errors or problems early. If unit testing is flawed or not occurring, this must to be remedied immediately. If several team members are submitting sub-standard work, the problem is more likely in the project plan itself. If you suspect a problem in the plan, begin by reviewing the tasks that came in under standards to see what (if any) quality standards, entry/exit criteria, or completion criteria were defined. In some cases, the answer is staring you in the faceno quality metrics or criteria associated with tasks means the work of defining the WBS was not fully completed. Go back and fill in all necessary details before proceeding. If your examination of the tasks doesn't reveal any problems, the problem is most likely in the functional or technical specifications. Review these specs in light of the task problems discovered and modify plans as needed.

11.5.2.2. Work Delivered Outside of Scope

Sometimes work that is delivered is outside the scope of work. To those performing the work, it may be considered an enhancement. To those testing the work, it might be considered a bug. Which is it and what do you do about it?

Possible solutions: First, check your scope statement and your project definition. Look at functional and technical specs related to this issue. First determine whether this issue is a bug or an enhancement. If it is a bug, it should be noted in the bug tracking system and fixed. If it is outside the scope but not a bug, you have to decide if you want it to remain there or not. Some "enhancements" may seem trivial at the time, but as you get deeper into the project, they end up having a long reach and impacting many other parts of the code. This type of scope creep may appear to be innocent at first, but you should carefully consider whether or not to let it stand. Even a seemingly innocuous enhancement can end up causing bug-like behavior when it interacts with other parts of the project. If you are unable to clearly understand the implications on the project, you should probably treat it as a bug and have it fixed to avoid later problems. In some cases, it really is an enhancement and may increase the final quality of the project. Analyze then select a course of action and stick to it. Vacillating on important decisions will eventually reduce your effectiveness as an IT project manager.

11.5.2.3. Fixing The Wrong Problem

When reporting any type of error or defect, it's important that the source problem be identified, reported, and resolved. If it's not, a lot of time and effort can be expended running after the wrong problem. Here's an example. You're staying in a hotel and you notice water on the floor in the bathroom. You report "water on floor in bathroom." The hotel manager sends someone up with a mop and bucket and mops up the water. However, the water soon returns. The manager sends someone back up with a mop, and so it continues. The real issue is not water on the floor, but a leak that is causing water to be on the floor. If you had reported "a leak that leaves water on the floor" the manager could have sent a plumber instead of a janitor. The same is true with quality problems in your project. Always look for the root cause and address it.

Possible solutions: The symptom is likely to be one person saying they fixed a problem (developer, tech) and another person (tester) saying the problem still exists. This can lead to bad working relationships on both sides and this type of back and forth should be quickly managed. The tester is looking at the product from the user point of view, while the developer or tech is looking at it from the project point of view. When these situations occur, you may be able to locate the underlying problem easily. If not, get several developers/techs and testers in a room to brainstorm about what could be the underlying cause. By getting the team to work together on this issue, you are subtly acknowledging the issue is bigger than any one person. This helps people "save face," an important element in effective team work. If the developer/tech feels he or she is being insulted or that their work is being questioned, he or she may become defensive and not fully participate. Make it clear that the work is fine but that there is an underlying problem that has to be discovered. Using their expertise, you can find that problem and fix it.

11.5.2.4. Problems Reappear

This issue is almost exclusively found in the software arena where a tester reports a bug, it gets fixed and later, the problem reappears. This is a likely sign that source control procedures are not being followed. Developers do most of their work with a local copy of the code running on their machine. This code may contain one program or hundreds, depending what is being developed. If one developer (George) fixes a piece of defective code, while another developer (Lorraine) has a copy of the bad code running on her machine then this can happen. George finds and fixes the bug and checks the code back in to the system library. Now Lorraine, who was working on another issue, checks her code back in. If the source library protocols are not followed correctly, Lorraine's code will overwrite George's fix and will reintroduce the bug back into the code.

Possible solutions: If you find this happening, meet with the developers (or development manager) and ask them to identify how this happened and what changes they will make to their source control procedures to avoid this issue in the future. Don't assume this is a one-time event. If one problem reappears, it may have been a one-time problem, but investigate it thoroughly. Process and procedure problems may initially appear as a single problem, but they will grow over time and you'll find that you have multiple problems reappearing. By the time this happens, you've got considerable confusion and frustration with the developers and a real risk to your code. This is a very serious problem that can create major havoc with the project. It can also create real morale problems when issues keep cropping back up. The good news is that most software projects have source control tools available and when used in a disciplined manner, they can help you avoid these kinds of issues.

11.5.2.5. Problems Cannot Be Resolved

Sometimes problems that crop up cannot be quickly or easily resolved. They may appear first as quality issues, but upon further investigation, they reveal deeper design problems. These instances may be rare, but when they occur, an IT project manager may spend several sleepless nights worrying about what to do.

Possible solutions: First, gather the team and discuss the issue. In this type of scenario, the more people looking at the problem, the better. Begin with an organized search for the problem by looking at the scope statement, the functional and technical specifications, the technology, and the chosen approach to the project. If the problem cannot be found, begin brainstorming about possible sources of the problem. Encourage the team to be really creative at this juncture to make sure that they cover every possible angle. If you encourage this type of investigation, it's likely the problem will be found. You may need to halt project work while this problem is being investigated to prevent the problem from rippling through the project. Be sure to gain project sponsor approval for delaying or halting the project and adjust your schedule accordingly. Once the solution is found, assess its impact on your schedule, budget, critical path, scope, and project requirements. Determine if the solution is feasible within the constraints of the project. This may require you and the team to go back and modify the project plan or simply modify some of the tasks, processes, or procedures within the project. If the problem cannot be resolved, the project should be tabled until resolution is found or terminated. Continuing on while your project is hobbled by an unsolvable problem of any size significantly reduces your chance of success. Some problems allow us to keep working while we find the solution; other problems are best solved when everyone stops work in other areas and focuses on addressing this one issue.

A final word on this scenario. It's wise to always try to separate out "discovery" work from "production" workmeaning you should not try to invent a new technology and put that new technology to work in the same project. A discovery project is far more uncertain and will have many more stops and starts than a production project. Don't start the production project until discovery is almost complete. This will help avoid unsolvable problems in some instances.

11.5.3. Problems with Schedule

Problems with the project schedule are often the most challenging because you're dealing with tasks both on and off the critical path. Changes to the project schedule can put the project at risk due to a variety of issues. Let's look at common schedule problems and possible solutions you can use to address them.

11.5.3.1. Late Start

Sometimes you can start project work already behind schedule due to earlier changes or delays or due to shifting requirements. Normally, you start the project schedule clock ticking once work gets underway, but if you have external milestones or deadlines to meet, it may not matter when your schedule "officially" begins. Late starts can start you off on the wrong foot, so try to avoid starting your project behind schedule.

Possible solutions: In some cases, you may be able to adjust your schedule to reflect the changes or delays that cause the schedule problem. Be sure to document the causes of the delay, especially if they were out of your control or outside your realm of authority or influence. Talk with your project sponsor to get approval for modifying the schedule to adjust for the unavoidable delay. If possible, you may find ways to shorten your project schedule. Sometimes analysis reveals opportunities to do tasks in parallel that were missed earlier. Sometimes you may choose to crash or fast track your schedule (discussed in Chapter 10), but these are serious actions that come with a certain degree of risk. Whatever you do, don't promise to make up lost time if you're not 100% certain you can do so. The rule of thumb is "under promise, over deliver." If you make a promise you can't keep, your credibility and political capital will fall. If you make a promise and deliver it with time to spare, you'll look like a hero. One word of caution about that: don't under promise to the point where your project sponsor thinks you're incompetent. If something should take a week and you promise it in three weeks and deliver it in two days, you will gain a reputation as either a terrible estimator or someone obsessed with covering your rear end. Neither view is flattering, so lean toward the pessimistic view of reality when coming up with new schedule commitments.

11.5.3.2. Floating Start Date

This problem can be similar to a late start, but it's a bit trickier to address sometimes. The start date is set then moves then gets set then moves again. A floating start date is dangerous because resources committed to your project can become unavailable if your start date keeps floating around.

Possible solutions: First, check that the project is aligned with corporate needs. If it's somewhere out in left field, you'll have trouble getting necessary commitments for the project to move forward. Along those lines, also check on the project's priority. It may be aligned with corporate goals, but it may have slipped down in priority due to other changes in the corporate business environment. Sometimes the start date floats because the planning stage drags on and on. In this case, set a hard deadline for completing planning so the start date can be set. Don't spend time creating detailed plans for work that is 6 or 12 months out. Create high-level plans for later phases, but don't spin your wheels creating detailed plans for distant dates in the future. Things will likely change by then and you probably don't have enough information to create a detailed plan. This sometimes leads to planning paralysis, so make a commitment to complete planning, don't shoot for detail on distance phases, and draw a line in the sand and get going. If you're wishy-washy on setting and sticking to your start date, you're going to have trouble throughout your project with deadlines and deliverables so learn to make and keep commitments. If your start date does float or change, you'll have to double check that needed resources are still available. Finally, if you can't pin down a start date, you might consider canceling the project.

11.5.3.3. Floating Completion Date

Some projects get off to a great start but seem unable to complete. These projects just seem to go on and on with no end in sight. A floating completion date means you've got one or more problems in your project that you should address immediately.

Possible solutions: First, look at tasks on your critical path. Which ones have slipped and why? Next, determine what is currently causing the float. When you can't pin down a completion date, it means that there is uncertainty, especially regarding tasks on the critical path. Next, check your scope statement and requirements. Double check that scope hasn't expanded while you weren't looking. Scope creep is the most common reason for a floating completion date, so be sure to check that. Review your WBS. Does your WBS define all the work that has to be done? If not, additional work may be going on that is needed, but not actually defined or scheduled. Another problem with the WBS is that tasks lack adequate detail and work packages or assignments become vague. Tasks should have plenty of detail in them, including entry/exit criteria or completion criteria. A task without these criteria could simply go on forever. Define what a completed task looks like so it can be completed. Also, double check that all tasks have owners. Some tasks may not have owners through oversight or through miscommunication and those tasks will not get done. These may be the tasks that keep floating around your project schedule and never get started because no one is taking responsibility for them. Floating completion date can also occur when you have a project that combines discovery and production. Separate the discovery portion of the project from the production portion and only begin (or continue) production work once the discovery portion is completed.

11.5.3.4. Missed Deadline or Deliverable

Missed deadlines or deliverables happen to everyone once in a while. The key is how and how well you handle these inevitable problems.

Possible solutions: It should not come as a surprise to you, your project team, or your project sponsor that a deadline or deliverable will be missed. That would be the equivalent of driving 80 mph right up to the edge of a cliff before applying the brakesnot a wise choice and almost always ineffective. Make sure you encourage (require) your team to keep you apprised of potential problems. If you recall from Chapter 10, encouraging your team to bring you the bad news will help you manage the project more effectively. Once you're aware of problems that cannot be corrected in a timely manner (that is, those that will cause you to miss a deadline or deliverable), work with your team to develop contingency plans, alternatives, or solutions to the problem. Determine what caused you to miss the deadline, what impact it has on the project, and what you can do to recover. Once that information is prepared, talk with your project sponsor. Over time, IT project managers that deal with problems in a responsible and proactive manner are given more responsibility and respect. Letting problems creep up on you and your project sponsor will not only put the project at risk, it could very well put your career at risk as well. It's often not whether problems occur, but how well you deal with them that will determine your successboth in your project and in your career.

11.5.3.5. Everything on the Critical Path

One common statement is "all tasks in the project are critical, so they're all on the critical path." While it is true that all tasks in the project are important (or they should not be in the project plan), it is not true that all tasks are on the critical path. By definition, the tasks on the critical path are those tasks that, if delayed, would delay the entire project. Conversely, these same tasks, if completed ahead of schedule, would cause the project to finish early. Let's look at an analogy. If you were driving from San Diego, California to Richmond, Virginia, there would be tasks that would be more important than others. For instance, getting gas would be on the critical path because if you delayed getting gas, you'd run out of gas someplace and you'd be delayed getting to Richmond. On the other hand, you may have a task defined as "clean bugs off windshield." This task will be done intermittently throughout your project, but delaying cleaning bugs off the windshield will not delay the project until the windshield becomes so filled with bugs you cannot see and have to slow down to drive. This task, then, can be done just about anytime within reason. If, however, it is delayed beyond a reasonable point, it can land on the critical path. Understanding the nature of critical path tasks helps you properly define them.

Possible solutions: If you believe all tasks are on the critical path, you have made an error in the defining your task dependencies, durations, and/or float. In almost every project, there are tasks that are not on the critical path that can be done just about any time. If you're installing a new server, you need the power to be in place before you can fire it up, but you don't need the nameplate that attaches to the server cover telling you the server's name. If all tasks in your project are on the critical path, review your task dependencies. If a task is not really dependent upon previous task(s), remove the dependency. If a task is not going to take as long as the duration in the plan indicates, adjust it to reflect reality. If tasks have no float defined, they may end up on the critical path. Add appropriate slack or float to reflect the reality of the situation. It's not uncommon that things shift after the initial project plan is created and updating dependencies, duration, and float to reflect reality will help you see your real critical path.

11.5.3.6. Nothing on the Critical Path

In some cases, you might think that there are no real dependencies. Using the server example, you might think "We can get that power installed anytime before next month" or "We can borrow backup tapes until ours come in." While these statements are true, they are misleading. Every project has tasks on the critical path.

Possible solutions: If you have a project plan showing no critical path tasks, something is wrong. Start by looking at dependencies. Ask what would happen if a task was delayed for a week, month, or longer. Once you understand the impact of the delay, you can determine whether a task is on the critical path or not. Also check duration and float. If you were loosy-goosy with duration and float estimates, it may appear that everything can move around to accommodate change. Review your duration and float estimates, especially for tasks you've determined would be a problem if they were delayed too long. This will help you begin to identify tasks that truly belong on the critical path. The overriding question is, "Will this delay the entire project if delayed?" If yes, it's on the critical path. The secondary question is, "Which tasks is this dependent upon and which tasks depend on this?" Once you've accurately identified dependencies, you'll begin to see your critical path emerge.

11.5.4. Problems with Budget

Some companies pay little attention to a project budget, while others review it with a fine-toothed comb. Regardless of how your company deals with IT project budgets, your job as IT project manager is to manage the funds allotted to you for the project. When a project ends up sideways due to its funding, the chances for project success are reduced significantly. Keep in mind that if cost is your least flexible project parameter, you should carefully and frequently review project costs to avoid these common problems. And, if you discover a problem with the budget, let your project sponsor know immediately. It's better to bring this problem to your sponsor than to have your sponsor bring it to you. Let's look at problems common to budget management and possible solutions you can use.

11.5.4.1. Funds Expended Up Front

An unfortunate but common scenario is you're halfway into the project and 3/4 of your funds are spent. This is an indication of one of two problems. Either there was a significant variation or you're not doing a great job managing your budget. Remember, though, that scope, schedule, budget, and quality are all interrelated. If you increase scope or quality or reduce schedule, your budget may burst at the seams. That might be perfectly acceptable to all parties involvedthe key is to gain explicit approval for such variances before they occur. If budget is the least flexible project parameter, you will have to explain why you have this type of variance. There may be a good reason such as purchasing equipment needed for a later phase of work at year-end for accounting purposes or to take advantage of a special pricing deal. These will net out at the end of the project but should be carefully reviewed.

Possible solutions: The first step is to look at what caused (is causing) the additional burden on your budget. In Chapter 10, we discussed sources for budget variance and what you can do to adjust for them. Some budget variances may simply be incorporated into the project (after analysis and agreement). Other budget problems will cause the project to be selected for special review (not a good thing). If your project risks cancellation because of these budget variances, you will have to do your best to make the business case for why the project should continue (if, in fact, it should). Sometimes the budget variance is a logical consequence of earlier, agreed-upon actions. Sometimes the budget variance is due to some value-added activity that will pay off at project completion. Other times, there may be no reasonable explanation for the variance and the decision to move forward or cancel may rest solely with the project sponsor or the Finance department. If the problem is because you've done a poor job managing the budget, you should review your cost control procedures and make adjustments to ensure you have tighter control of your budget moving forward. If your reserve amount can handle the variance, you may be able to salvage the project if your adherence to budget moving forward is greatly improved. Hold weekly budget review meetings and insist on giving your personal approval for all expenditures over a certain (low) amount to help you get your budget back on track.

11.5.4.2. Assets Moved Off Project

Sometimes you'll purchase assets of the project that will sit idle for some period of time due to changes in the project schedule or other unanticipated changes. Occasionally, those assets will be appropriated by some other department or team and suddenly your new servers or new routers or new whatever are in someone else's domain or department. Sometimes someone sees hardware sitting around unused and sees it as a bone yard for scavenging parts.

Possible solutions: The key is to determine why the assets were taken, who took them, and why. This is not an exercise in finger-pointing, but a fact-finding mission. If the assets were taken for a higher priority project, that's fine. If they were used for spare parts, that's also ok. The key is to understand how and why they were taken so you can build the business case for getting them back. Talk with your project sponsor about the situation to determine the best course of action. Sometimes the best resolution is to take a hit to your budget and go purchase new equipment. This would be done with your project sponsor's explicit approval. If possible (depending on your corporate culture and accounting system), you may be able to assign the cost of those appropriated assets to that other division or department so your budget won't take a hit. If you have to use your reserve amounts to deal with this type of situation, document exactly what happened so there is not any question about the loss of corporate assets. If the servers are now in another location or were used for spare parts, make a note of that. You don't need corporate controllers coming back to you asking if you took three or four servers home with you.

11.5.4.3. Too Many Approvals To Spend Your Budget

Part of defining your project is to agree with your project sponsor as to what, where, how, and when you can spend your IT project budget. However, some companies have so many approval layers and so much red tape that it becomes a project in itself just to get approval to spend IT project funds. In these cases, delays in funding approval can throw the schedule off, causing a ripple effect throughout the project.

Possible solutions: If it's taking too long to get approval, consider asking your project sponsor for a monthly allocation that you can spend. Make sure it's not a "use it or lose it" allocation so that it can pile up for a month or two or three for large, upcoming expenditures. If that's not feasible, consider asking your project sponsor for a "fast track" funding option so that you can get project expenditures approved in a more timely manner. A third possible solution is to ask for an increase in the amount you are authorized to spend, at least for the duration of the project. It might be that in normal circumstances, you'd need approval for each expenditure over $500, but for the duration of the project, your limit is increased to $1000 or $1500. If none of these options is acceptable to your project sponsor, you should try to document the business case for modifying the spending limits or approval process. There is a cost to schedule delaysboth tangible and intangibleand a polite reminder of these consequences for your project sponsor might prompt the change you need.

11.5.4.4. Shrinkage

Experienced IT project managers are familiar with shrinkage. It often stems from a memo from the CEO that begins "Due to changes in the marketplace, we're cutting all project budgets by 15% effective immediately…." Ouch. All that diligent project planning seems to fly right out the window. Since you're aware that there is a relationship between scope, time, cost, and quality, you immediately know that if your budget is reduced by 15% you will need to reduce scope or quality or increase time to adjust for the budget change. The question is, what do you do next? No matter what course of action you take, whining about the cutback is not likely to change the outcome and it's a sign of poor leadership. Look for ways to meet the new requirement and position yourself as part of the solution, not part of the problem. You may not be happy about the requirement to cut your budget, but you have to deal with it as the IT project manager.

Possible solutions: First, review your flexibility grid. If budget is your least flexible (and it was just reduced by 15%), you know that something else must be most flexible. Begin by looking at that parameter to determine what you can adjust. For example, if cost is least flexible but schedule is most flexible, you may find that by stretching out your schedule, you can reduce the cost of the project. If not, you have to move up your flexibility grid to your next most flexible parameter. Once you've determined your approach to cutting your project budget by 15%, you need to assess the risks associated with making the proposed changes. Ideally, you and the team will devise two or three possible solutions and prioritize them (remember, canceling the project may be one of them). Once you and the IT project team have developed your recommendations, you should meet with your project sponsor to discuss proposed solutions.

11.5.5. Problems with Staff

At several points throughout this book, we've discussed working with your IT project team from recognizing and managing differences in work styles and cultures to providing the necessary ingredients to create a highly effective team. Despite your best efforts, teams sometimes run into problems. If you find yourself with a problem related to your project team, you might find solutions in this section. If not, be sure to turn to your manager, another experienced IT project manager, or your friendly HR department for advice on resolving personnel issues.

11.5.5.1. Matrix Organization (Who's Staff Is This Anyway?)

One of the most common team-related problems you may run into is conflict over who belongs to whom. When someone is pulled from a department to work on a project team, to whom do they report? Who holds them accountable? What are their priorities? These kinds of unresolved problems cause stress for the person caught in the middle and reduce productivity and the quality of their work.

Possible solutions: Discuss the project with the functional or departmental managers who will be lending staff to your project. Explain to them the project's objectives, what you'll need the selected person to do, and what your timeframe is. Come to mutually acceptable agreements about how you'll handle conflicting priorities before they crop up then rely on your agreed-upon procedures when these issues arise. Anticipating and planning for these kinds of problems goes a long way toward avoiding them. If they can't be resolved in this manner, sit down and have an honest, open discussion with the manager explaining what is happening and how it impacts the project. Rather than expecting the other person to give in to your demands, come prepared with several possible solutions along with your recommendations. This will help resolve sometimes sticky issues by showing you're willing to work through problems, arrive at the table with potential solutions, and give a little.

11.5.5.2. Whiners

A whiner isn't someone who brings up the negative or downside of a situation. It's someone who does that and never looks for the solution. They can be irritating at best and few, if any, people want to work with people like this.

Possible solutions: If you have a whiner on your team, you need to assess whether they're adding enough value to the team to justify keeping them on board. Whiners can de-energize entire teams and take the energy, excitement, and enthusiasm for a project and deflate it quickly. If you can't or don't want to remove the team member, you'll need to manage this behavior. First, require that your team make meaningful statements about the problem that are specific, measurable (if possible), and realistic. For instance, saying "The code from Section Seven is garbage" is not meaningful by any measure. A statement such as, "There are fourteen critical errors in the code from Section Seven," is far more useful. Next, require that every time a problem is mentioned, a solution must also be offered. It doesn't matter much if the solution is feasible or desirable as long as problem is offered with a suggested solution (or two). This will prevent problems from just being lobbed out for the team to deal with. Instead, some thought will have to accompany problem statements. Who knows, you might also find a great solution along the way by requiring the naysayer to consider possible solutions. Make this a rule for everyone, not just your whiners. Meaningful problem statements paired with possible solutions will change this dynamic quickly.

11.5.5.3. Big Biters

People who take on too much can cause major or minor problems for projects because they typically lack self-awareness as to how much they should commit to, based on their time and skills. If you don't manage these folks, they can tank your project by signing on for more than they can handle then failing to deliver (scope, time, cost, or quality) on those deliverables. Self-confidence and enthusiasm are wonderful traits in measured doses.

Possible solutions: Encourage "big biters" to take on small segments of work until you verify whether or not this person has the time and skills to deliver. In some circles it's referred to as "trust and verify," meaning that you place a small amount of trust in the person and verify whether that trust was justified or not. If it was, you can place additional trust and verify that level and so forth. By carefully managing the big biter, you can help them grow in awareness of what they can and cannot do while keeping your project safe from the "over promise, under deliver" syndrome many big biters bring with them.

11.5.5.4. Belt and Suspenders

We all know someone like thisalmost completely risk-averse. Their avoidance of risk could come from prior bad experience in which they got burned or it could simply be their personality or work style. The analyst types we discussed in Chapter 4 can sometimes really have problems with change and risk. If you have these types of people on your team and your project requires some level of risk, you're going to engage in a tug-of-war with them throughout the project process.

Possible solutions: If you are working on a risky project, these risk-averse people are not good fits for your team. If you cannot replace them with team members more comfortable with risk, try to find parts of the project that will utilize their skills and talents. Since these kinds of people can be very good at spotting problems (they look for risk so they can avoid it), you can engage them fully in your risk assessment and management tasks as well as some of your detail work such as creating the WBS and task details, helping manage the costs and schedule of the project, and other less risky tasks. By assigning more mundane roles to these folks, you utilize their innate talents while offloading some of the routine project management tasks to someone else, freeing you up to work on tasks that may require more of your bandwidth. Don't let their fear of risk or failure rub off on the team, though. Keep the project moving forward, and if you find they are causing delays due to risk aversion or through planning beyond a reasonable point (analysis paralysis), take action to move them off the task or out of the way to keep forward momentum.

11.5.5.5. Personal Conflict

As we discussed in Chapter 4, your role as IT project manager includes creating a positive work environment for your team. This is especially true when dealing with people of different ages, backgrounds, cultures, and languages. Your HR department is probably your best resource for advice on handling sensitive issues, but we'll discuss some possible solutions here as well.

Possible solutions: First, you should have a zero tolerance policy for rude, intimidating, belittling, or disrespectful behavior. Some behaviors can lead to a hostile work environment and may lead to legal issues down the road. If you're unsure or if you're concerned, consult with your HR department immediately. Do not discount or trivialize these issues because they not only cause immediate problems, but they can have serious long-term consequences as well. That said, you may encounter conflicts between team members that are impacting the team but are not serious enough to bring to your HR department. To resolve interpersonal conflict you can:

• Talk privately to each individual involved in the problem. Listen to each individual's perspective. Conclude the conversation by asking them what they would change about the situation and what they would be willing to change. This sets the stage for a negotiated settlement and helps them understand they will likely have to give something to resolve the situation.

• Once you have each person's perspective along with their lists of what they would like to see changed and what they'd be willing to change, put together a recommended solution (or two or three, if possible). Gather everyone in the room and discuss solutions based on the information they gave you.

• Once a resolution has been forged, enforce it.

• If anyone reneges on the agreement, address it with them immediately.

• Remove people from the project who are unable or unwilling to resolve personal conflict through negotiation and mediation. They'll steal project time and energy and wear everyone out in the process.

11.5.6. Problems with Project Sponsor

Taking time to develop a strong, open, and honest relationship with your IT project sponsor can pay off handsomely down the linewhen things go right, you'll get appropriate credit and rewards, and when things go wrong, you'll get appropriate political cover and support. Keep it real with your project sponsor and always be the one to bring the bad news to the sponsor. If your project sponsor hears bad news from another source before you report it, your credibility begins to erode. Most people hate being ambushed by bad news, so make sure you stay on top of things and communicate with your project sponsor in a proactive and timely manner. That said, there are problems that can crop up with your project sponsor, including the ones listed here.

11.5.6.1. Project Report Grows Lengthy

Sometimes a project report ends up getting longer and longer until it begins to rival War and Peace. This is not productive for you as the IT project manager and it's probably not helpful for your project sponsor either.

Possible solutions: What to include in the status report should be determined at the start of the project, but it is often not well defined or not known in advance. Try including just four basic elements when reporting project status:

• What has been accomplished since the last report

• What is planned to happen during the upcoming period until the next report

• What items have missed the schedule or are over budget and what their status is in a summary format

• What items are of concern that have to be addressed

The goal is to provide a one- or two-page summary of the project status and make sure any items that are a risk to the project are seen by management so they can be acted on as early as possible. If you provide too much detail, you also risk having the project sponsor (or other executives) begin to micromanage your project for you.

11.5.6.2. Meetings Become Rehash of Prior Decisions

Sometimes meetings with project sponsors become reviews of decisions previously made. Constantly reviewing previous decisions makes it difficult to get any forward momentum going and it puts your project at risk because, conceivably, every decision made could be reversed.

Possible solutions: If you and your project sponsor keep rehashing the same decisions, it could be a sign that the sponsor is nervous about the project. If that's the case, ask yourself:

• Are your project status reports accurate?

• If you were in your project sponsor's shoes, would you be nervous?

• Are you making decisions above your level of authority?

• Have you taken risks that have not panned out?

• Has your project sponsor been hit by any surprises or unexpected bad news regarding the project?

If your project sponsor feels he or she is not getting straight answers or the level of detail needed to accurately assess the project's health, he or she might begin to go back over old decisions with you. Go over your concerns with the project sponsor, give specific examples of the problem and really listen to the feedback you get from your project sponsor. If your project sponsor is a real hands-on type of person and can't seem to let go of these decisions, you may need to create a more detailed process for signing off on decisions so they do not have to be revisited. For instance, you may need to keep detailed notes about how, why, and when the decision was reached, what the environment was, and what factors went into the decision. Then, if the sponsor wants to revisit a decision, you may be able to discuss the document you have and ask what has changed to cause you to revisit the issue.

11.5.6.3. Can't Arrange Meetings with Sponsor

Project sponsors are often busy people like the rest of us. If you are unable to schedule time with your project sponsor to discuss project progress, one of three things is likely wrong. It's possible the project has slipped in priority and you don't know about it. It's possible the project sponsor's priorities have changed even if the organization's haven't. It's also possible that the project sponsor is just too busy and meetings with you fall off their "to do" list.

Possible solutions: If possible, first determine if the organization's priorities have shifted away from your project. If it seems that's the likely cause of the problem, insist on a meeting and let the sponsor know that you realize priorities may have shifted. If the sponsor wants to avoid this session because he or she doesn't want to deal with the negative impact, your mentioning this might pave the way to an honest and useful discussion. If the project sponsor's priorities have shifted and you've been able to discern that, it might be time for a different project sponsor. In that case, you should identify your desired or optimal replacement sponsor and define your rationale for such a request. Then, contact your project sponsor and let him or her know that you believe the project might do well to transition to another person due to this sponsor's workload, commitments, new direction, etc. Be very careful not to make this about the project sponsor failing as a sponsor, but about the changes that have occurred within the project sponsor's work or environment that make changing sponsors a logical action. Finally, if your project sponsor just claims to be too busy, be ready to be incredibly flexible to get some face time with the project sponsor. Come in early, stay late, offer to go get sandwiches for an in-house meeting, arrange a video call or cell phone call while you (or the project sponsor) is traveling, talk on Saturday morning at a local coffee shop. Do whatever it takes to get face-to-face with your project sponsor on a fairly regular basis. Be creative and offer solutions such as offloading non-critical tasks (signing project time cards, for example) to someone else with proper authority or look to bring on a project cosponsor to take up some of the work. Whatever you do, do not assume that just because you can't get a meeting that the project sponsor is just fine with what's going on. Remember the old project management saying, "No news is simply no news."

11.5.6.4. Project Sponsor Pressure

The project sponsor is under pressure regarding the project just as the IT project manager is. The key difference is that the project sponsor will pass that pressure on to you and sometimes you feel as though you may buckle under the pressure. Here are some simple solutions that can help you deal with that type of project pressure.

Possible solutions: First, be prepared. Make sure your project data is up to date, that your team provides you updates that are accurate and timely, and that you, in turn, provide accurate, timely, and meaningful data to your project sponsor. If your project sponsor is up to speed on the progress of the project and understands the risks, challenges, positive, and negative events, he or she will be able to properly explain (and in some cases, defend) project results to corporate management or executives. A good offense is the best defense, so make sure you're on top of your project's status. If your project sponsor has signed off on the major components of the project as you've gone along (as suggested throughout this book), you should have an easier time dealing with some pressure because you can take these decisions points back to your sponsor to spark his or her memory. If you're getting pressure to complete the project sooner, for instance, you can discuss scope and schedule with your project sponsor and come to agreement as to how to proceed or how to fend off further schedule pressure. If you've developed a good relationship with your project sponsor, you can have an honest, open discussion about what the drivers are and together develop a plan to address these added pressures.

Cheat Sheet…
Being On Top of Your Game

A project manager has lots of pressure and your sponsor will certainly provide a share of it. You can control this pressure by being organized and having an ironclad reporting system. "On my projects, I produce a weekly status report on Fridays. I stay as late as possible to get it done on Friday, but if it is not done, I finish it on the weekend," explains Nels Hoenig, Quality Assurance Project Leader for TDCI, Inc. "My publish date is Monday at 9:00 A.M. This hard date keeps me focused. It also means my sponsor knows she can count on being prepared for her staff meeting at 10:00A.M. I hold my team responsible for having their reports to me by end of the day on Thursday and I am very strict about this. Since I'm not pestering them 25 times a week on status questions, they deliver their status updates on time and we all can spend the rest of our time on the items that are critical or that can become critical if not resolved. This also gives me Friday to chase down and solve any issues that need to be addressed prior to finalizing my report."

Nels also produces a monthly project report that provides a high-level view of the project. It includes information on budget and schedule including plan versus actual. He also includes good and bad news about the project so that everyone remains up to date and helps ensure that everyone hears the same message.

11.5.7. Problems with Project Vendors

We haven't focused on managing vendors, since vendors take so many different forms. However, vendors should be treated as part of the project team from the beginning so they are included in key project communications including timelines and deadlines. Written contracts should be used to clarify costs, timelines, and deliverables. Someone on the project team can be assigned as the vendor liaison (or several team members, depending on the number of vendors) to oversee the vendor relationship. Most vendors want to do a good job and will work cooperatively with you to define portions of the project they'll be working on and to help develop specifications for work. Be sure to develop acceptance criteria that will indicate to the vendor when you will sign off on or accept their deliverables. Define early delivery bonuses and late delivery penalties. And remember to get a vendor point of contact and all contact information including name, address, phone, cell, e-mail, etc. so you know who to contact for routine or emergency communications. It's helpful to spell out in detail which process will be used to resolve disagreements to be sure that everyone is on the same page (and to avoid surprises). Contracts written by attorneys as well as standard (boilerplate) contracts often contain these details, but it's a good idea to make sure they're included in your contracts. Despite your earnest efforts, you may still run into vendor problems. Here are a few common problems and potential solutions.

11.5.7.1. Vendor Does Not Deliver As Promised

The biggest problem facing an IT project with regard to vendors is when a vendor does not deliver as promised. Whether it's needed test equipment, software code, or new servers for the upgrade, vendor delays can put your project behind schedule quickly. If the product or service the vendor is providing is critical to the project (tasks that depend on these are on the critical path), you should have identified them as risks and developed contingency plans for these scenarios. Any external event (including vendor deliverables) over which you have little (or no) control presents a project risk and you should include these in your risk management plans.

Possible solutions: The first step is to find out why the vendor did not deliver as promised. Is the issue quality, quantity, or delivery altogether? If the vendor shipped defective parts, it's the same problem as not shipping at all. Your contract should specify your remedy should you have problems with the deliverable including reordering on an expedited track. If the vendor is unable or unwilling to deliver the items, you will have to locate an alternate vendor and expedite the order if possible. Don't wait until the shipment is delayed two weeks to check on it. Check on deliverables before they are due so you know if there is a snag in the process. If there is to be a delay, see if you can schedule other work around the delay so you don't end up pushing your entire schedule out. If the vendor short-shipped items, you may be able to begin work in a staggered manner instead of waiting for all parts to be present. In some IT projects, this presents problems and introduces unacceptable risk. In other IT projects, a staggered start on this part of the project work is acceptable and causes only a few rescheduling events.

Obviously, if you have continued problems with the vendornot only in terms of deliverables, but in terms of their attitude toward addressing problemsfind another vendor. Projects can be delayed or can fail altogether because a vendor was unwilling to address issues or unable to deliver as promised. Don't get into the mindset that this was a one-time event. If a problem occurs and the vendor handles it promptly and appropriately, you can chalk it up to "mistakes sometimes happen." If mistakes happen frequently or the vendor is slow to resolve issues (or completely unwilling), find a new vendor because things will rarely get better.

11.5.7.2. Product or Service Does Not Meet Specifications

When a vendor's product or service doesn't meet project specifications, there are several potential problems that could be the root cause. Before blasting your vendor, be sure to look at your own project plan first to determine what your specifications actually are. You may find the vendor met your specifications, but you (and the project team) were mistaken about the specs. This can happen when specifications change or when a subject matter expert (including someone from the vendor company) recommends a different or better way to approach a specification.

Possible solutions: First check that the vendor's deliverable really doest not meet specifications. It's embarrassing to blast a vendor only to find out later you were wrong. Once you're sure the vendor's product is out of spec, talk with the person on your IT project team that worked with that vendor. Review the vendor paperwork. What you want to find out is if you properly communicated the specifications to the vendor in the first place. If you told the vendor there was a 5/8" clearance and it's really on 3/8", the problem is on your end and you'll need to work with the vendor to find an appropriate solution. Once you've determined that your specs are correct and that the vendor was given the correct specs, you obviously need to contact the vendor. Ask them to review their specs and processes to determine what went wrong and what they can do to remedy the problem. Be clear about timelines, deadlines, and costs when talking with them so they know exactly what they'll need to do to resolve the issue. If the issue requires research on their part, get them to commit to a follow up meeting or phone call on a specific day and time. This will put clear boundaries on their research and resolution period and will not push your schedule into an interminable "float". Also, by telling them what the problem is and asking them for the resolution, you put the onus on them to resolve an issue they created. In some cases, they may come back with a better resolution than you would have requested. If you find the vendor is unwilling to admit to their error, review the specifications and contract with them. This helps you be sure the problem is on their end and essentially pushes them into accepting responsibility. If they still will not resolve the issue, you may have to escalate it to your project sponsor or even to legal counsel for resolution, if appropriate. If they are not cooperative, you will have to continue to push for resolution with them and simultaneously identify a new vendor to fill in. As soon as possible, sever the relationship with the non-responsive vendor. Put them on your "do not use" list for future projects. Mistakes are one thing, refusing to take responsibility for errors is another matter altogether. The first can be fixed, the second is an attitude or company culture problem that goes to the core and will rarely, if ever, change.

11.5.7.3. Vendor Does Not Communicate

Communicating effectively with vendors is a key part of effective vendor management. If you have a vendor with whom communications are difficult or impossible, this should raise a red flag for you because it means if you run into a problem down the line, you'll have a very difficult time chasing down someone to respond to your issues.

Possible solutions: Make sure you have the correct vendor contact and current contact information. Insist on a personal e-mail address (as opposed to "customer service," "marketing," "sales," or "info") and a cell phone number. If you are unable to reach your contact, call the main vendor phone number and ask for that person's supervisor. If unavailable, ask for the next person up the line until you get a human being on the phone who can respond to your concerns. Be politely persistent. If the vendor contact says he or she will return your call at 10:00 A.M., get on the phone at 10:05 A.M. and call them. If they do not answer, leave a message and state another time you can be reached or provide an e-mail address. Don't let communications slide, insist on timely responses, and escalate issues in a timely manner. Sometimes your contact may have left the company or gone on vacation without your knowledge, so leaving repeated e-mails or voice mails will not resolve the issue. Therefore, if you don't get a response in a reasonable timeframe, start working you way up the ladder. It might make your vendor contact angry, but your job is to get your project completed on time. Be polite but persistent. If the error is yours or you jumped the gun in escalating, apologize and move on. One incident like that, though, is often enough to spur your contact to respond in a more timely manner in the future.

The IT Factor…
From the Vendor's Perspective

"Most vendors want your business and they strive to create a mutually beneficial relationship," explains Sonal Rana, Systems Analyst with an international consulting firm. "When problems crop up, it's often a case of miscommunication rather than ill-intent. Stepping back from the situation and approaching it from another angle can help you resolve the matter. Start with the mindset that everyone has good intentions and something went wrong along the way. If you start off blaming and accusing, you're not likely to get an honest answer or a positive result. When dealing with companies from other countries or cultures, keep in mind that words and phrases may not have exactly the same meaning or intent. Cross-cultural communications can be complicated, so check for understanding by having the vendor explain to you, in their words, what they believe is expected of them. This can help you avoid simple miscommunications that end up delaying an entire project."

11.5.8. Problems with Customers/Users/Stakeholders

Problems with customers, end users, or stakeholders (whatever the case in your IT project) come in several different forms. In some cases, the user (we'll use "user" here for all those terms) isn't clear what the project deliverables are supposed to be and is therefore displeased with the results. In other cases, user requirements have changed and the deliverables don't meet user needs. In still other cases, the user gets stubborn about some elements of the project.

11.5.8.1. Users Are Not Pleased with Project Results

At some point during the project work and reporting, it becomes clear that the user is displeased with the project. This is a difficult situation that can cause problems both in terms of real and perceived success of the project.

Possible solutions: It is during the definition of project scope and functional requirements that the project begins to meet user needs. Users (or a select subset of users) should be involved with defining these specifications from the start. Two things should happen at that point: the user is clear about what is and is not included in the project and the IT project team is clear about what the user needs and wants. Having a formal approval process for functional requirements that the user signs off on is very helpful in preventing the users from changing their view of the requirements of the project once work is underway. It can also be helpful to review this document with users periodically throughout the project lifecycle to ensure that user requirements are the same.

11.5.8.2. User Requirements Have Changed, Project Doesn't Meet Needs

Sometimes major unanticipated changes happen in the user world that might require you to go back and redefine functional requirements. What was acceptable two or three months ago is now only part of the picture. This type of change is a major event in your IT project. Let's look at how you can handle this.

Possible solutions: If major change occurs in the course of the project, you can use the approved functional requirements document as your starting point for discussion rather than reinventing the wheel. First determine what has changed in the user environment and map it to deliverables in your functional specifications. Next, figure out what has to change to accommodate user needs. Assemble the project team and step back through the relevant definition and planning steps, including defining the new functional and technical specifications, as well as defining new scope, time, schedule, and quality parameters. Look at the risk to work completed to determine how these changes will impact work already completedwill you have to redo work or can you implement change moving forward? Finally, put all this together in a report or analysis and discuss the results with your project sponsor. Delivering a project that no longer meets users needs is a useless and wasteful exercise, but you must assess how much of the change (if any) you can accommodate. Remember, there may be times when canceling the project is your best bet. Other times, you may need to drastically revamp (that is, start from scratch) your IT project plan. The better job you do on the front end defining requirements and getting user buy-in, the less likely this scenario is to occur. That said, the unexpected can happen in the user's world just as it can in your world and by devising thoughtful responses and solutions, you'll be seen as a problem solver and team player.

11.5.8.3. User is Picking and Choosing Among Deliverables

This problem is most common when the user is an external client who is being billed for services. Sometimes during the definition or delivery phase of the project, the user starts nitpicking project details. In some cases, they might agree to large expenditures and then nickel-and-dime you to death on small details. It can happen at the outset of a project, sometime during project work, or when work is being delivered.

Possible solutions: Help the user understand the end-to-end benefits of the project proposal or project plan. Define the functional specifications based both on user need and project need and educate the user about project needs. A good example is if the user agrees to buy an expensive new tape backup unit but doesn't want to buy new tapes so they insist you spec out a tape drive than can use their current tapes. Your job will be to educate the user and this often means making the business case for your decisions. If the tape backup drive you recommend is more reliable, handles more data, is faster or more secure, make sure you educate the user about this, especially if you believe they're starting to nickel-and-dime the project. The cost of new tape might be the real issue for the user/client, so try to figure out what the real objection is to your plan is and address that. If the user is reluctant to pay for new tapes, do the math for them. Figure out the cost of a new set of tapes and compare that to potential backup issues (slow backup due to rewrites, bad backups due to tape errors) as well as the cost of a total system outage because of worn out, unreliable tapes.

Enterprise 128 …
Penny Wise, Pound Foolish

Sometimes users demand the very best from an IT project. They're happy to spend thousands (or tens of thousands) of dollars on the latest hardware and software. They want top-of-the-line everything and are willing to pay you overtime to get everything ordered, tested, and installed in record time. During the project definition phase, however, they become reluctant to spend an additional $100 or $500 on some critical part of the solution. "What some clients fail to realize is that it's usually a case of pay a little now or pay much more later," explains Chris Compton, President of TCR Solutions, an IT service firm. "When we recommend the customer purchase a $500 UPS system to avoid problems with power outages that occur every year in the summer as part of an upgrade project, they sometimes balk. Later if the system goes down, it often costs 10 or 20 times the cost of the UPS when you add up the replacement cost of hardware, the cost of our time to replace and reinstall everything, and the lost productivity," says Compton. "We've begun developing business case scenarios for our clients to help them understand the cost of prevention vs. the cost of recovery. In every case, prevention has a much higher ROI (return on investment). We've begun to build this into our IT project proposal phase to help clients make better long-term decisions."

Lesson Learned: When your users, customers, or clients balk at taking the right steps to ensure project completion or success, make sure you step back and help them see the bigger picture. Like life insurance, you don't buy it because you want to use it; you buy it because you hope you never have to use it. If your customers want to play the odds, make sure you've made the business case and then documented the decisions thoroughly to prevent these short-sighted decisions from coming back to bite you and your IT project team.

11.5.8.4. The Impossible Project

Sometimes users, stakeholders, project sponsors, and others insist on what essentially can be called an "impossible" project. They want you to accomplish too much work in too little time with too few resources. This is a disaster waiting to happen and you don't need to be the poor sucker who walks into that one. First, you should learn to recognize "impossible" projects early on so you can try to avoid becoming involved with them. They are:

• Projects that combine discovery with production

• Projects that are poorly defined or planned and lack adequate detail

• Projects whose plans have been modified by management (shorter schedule, lower budget, higher quality, and/or increased scope)

• Projects with wrong or inadequate staffing

• Projects that keep slipping the start date

• Projects that are underway but show no sign of progress

• Projects that "depend on you to save them"

• Projects that appear to have political problems

• Projects that have no meaningful organizational support

One common problem is that a confident or experienced IT project manager may think, "I can fix this," especially if you have a knack for fixing problems in projects. However, to step into a troubled project is really a huge career risk for several reasons. You could be being set up to fail, either intentionally or not. You could be saddled with a terrible project that will prevent you from working on a project that could be successful and add value to the company and to your career. You could become so mired in this troubled project that you get pigeon-holed and moved off into some obscure career corner of your company.

Possible solutions: Though it may sound deceptively simple, the best solution is to avoid these projects whenever possible. Keep your ego in check and don't rush in to save the day. Instead, look for opportunities to apply your skills and expertise to a new project so you can build it properly from the ground up. If you do get saddled with one of these impossible projects, follow these guidelines to help maintain your sanity and your sterling reputation:

• Don't overcommit. Promise less than you think you can deliver across the board. Unfortunately, even these scaled-down commitments may end up being ambitious.

• Don't commit to any project parameters until you're confident they're correct. That includes scope, time, cost, and quality, as well as functional and technical requirements.

• Present your worst-case, most pessimistic scenarios and estimates. Normally this is not a wise course of action because you want to be viewed as an IT PM who can come up with accurate estimates. However, when dealing with an impossible project, your worst-case scenario is most likely correct or not close to bad enough. Don't compound the issues in this project by taking a more moderate view of things.

• Identify where this project fits into corporate goals and priorities. If it's not a high enough priority or if it's not aligned to corporate goals, try to persuade the powers that be to cancel the project or redesign it.

• Find ways to get others to have a vested interest in the outcome. There is power in numbers and if you can get enough influential people to have a vested interest in the project results, you might then find enough organizational clout to actually get the project moving in the right direction. If you're the only one with "skin in the game" you're in a very risky position and it will be your career, and yours alone, that tanks if things go bad.