Complex IT Project Management: 16 Steps to Success

13.7 You Can Run, but You Cannot Hide

Remember where we are in the project cycle. Probably, there is a proposed set of deliverables and a tentative schedule, but nothing is set in concrete. Perhaps I am a little naïve, but the things beneficiaries squawk about still surprises me, and what does not appear to bother them at all during this process. In other words, if I bet on their objections beforehand, I would lose most of the time.

So be it. Let us regroup. We have previewed the project and discovered that the beneficiaries have issues with our plans. Truth be told, they had probably already heard rumors about the project prior to your presentation and took the time to brew a few objections beforehand. If you managed these objections satisfactorily, you have, at least for now, snuck the ball over the net to their side. Because their participation in your project is undoubtedly mandatory, however, at some point these objections must be resolved. Only a few outcomes are possible (see Exhibit 6), whether the issues are technological, logistical, or financial.

Exhibit 6: How Objections Get Resolved

It is incumbent upon you to understand the beneficiary's point of view. Earlier, we recommended the application of empathy in response to beneficiary concerns. Empathy, even in the workplace, is more than the simple application of tact. To understand what this means, it is useful to understand the two common types of beneficiary objections.

1. Reluctance to participate. I have personally experienced many versions of this, ranging from a mistrust of proposed new technologies, to resistance to a major corporate relocation based on issues of geography and culture.

2. Risk avoidance. At the start of this chapter, one of the key beneficiary issues I always look for was expressed, in their voice, as "What will this project do to me?" If beneficiaries believe that risks outweigh benefits, objections will be elevated in direct proportion to the damage they fear.

It is my belief that one must categorize major objections as being in either of these two classes because that will, in turn, dictate your strategic response. How so?

Reluctance to participate generally leads to a myriad of seemingly unrealistic objections. Depending on the political weight behind the resistance, this type of objection is likely to lead to concessions being made by the corporation to make the objectors more malleable, if not cooperative. The form that concession takes depends on many factors. The most extreme case I can cite involves the corporation providing millions of dollars in subsidies to the complaining business unit to provide budgetary relief for beneficiary costs accruing from the project that it was originally assumed the beneficiary would willingly pay.

If risk avoidance is driving objections, a different strategy will likely emerge. This is where empathy really comes into play. Basically, you put yourself in the beneficiary's shoes. Your goal is to understand what risks they feel are appropriate to elevate in the form of objections. The way to start is to ask yourself what changes your project will introduce into the beneficiary environment that could disrupt their workflow. Here are the likely suspects:

• Business as usual (BAU) work processes. A beneficiary's environment can be assumed to have a cyclical nature that is based on their work. There would be associated deadlines, and possibly blackout periods or maintenance windows that you need to understand as potential scheduling dependencies.

• Resource issues. Your project may demand time from key beneficiary personnel that creates inconvenience for the beneficiary organization. Although they may present their world as running more smoothly than the best Swiss watch, the converse to this is far more probable.

• Legacy systems stability. Operating system or browser upgrades can wreak havoc with applications, particularly those written in-house that are more than 3 years old. One wrinkle on this is the enforcement of corporate standards. Project-driven server builds, for instance, may require the installation of specified revision levels as the project adheres to corporate standards. Older servers may be back-revved and thus incompatible with the new standards. This kind of problem is difficult to anticipate and even harder to fix.

• Access to systems, applications, and data. The Domain Name System (DNS) is a wonderful thing, but many programmers and integrators use hard-coded Internet Protocol (IP) addresses that may cause applications to no longer be accessible under certain project conditions. We had a beneficiary lose access to an external application site when we reengineered the security devices protecting the network. This is another difficult risk to forecast, because far more renegade (i.e., undocumented, noncompliant) network connections, servers, and applications are deployed in the environment than you might think. In this example, even though the connection was in violation of corporate security standards, the project caused the outage, so we were on the hook for its resolution.

• Operational considerations. The care and feeding of applications can involve processes that projects compromise. This potential set of risks includes change control for application updates, tape backups and restores, disaster recovery (DR), and regularly scheduled database refreshes such as mainframe downloads. These risks can emanate from server relocations, network changes, resource moves, and network or operating system upgrades.

• Financial considerations. Examples of this have been referenced throughout the book. Your beneficiaries may have to expend real money to accommodate your project. Or, they may be saddled with depreciation or usage fees when they "accept" project deliverables, such as hardware, software licenses, or network access fees. This can mean millions of dollars to them. You may be enamored of the project, but they may wonder what benefits are obtained for such a sizeable expenditure. That is why you must do such a great job of understanding and evangelizing on that very topic.

Other potential risk issues must be considered as well, but this list highlights the most common ones. Depending on the nature of your project, it is highly probable that beneficiary risk avoidance objections can be traced back to this list. Also keep in mind that the risk may be technically possible, though unlikely. Or, if it does come to pass, the actual impact would be far more negligible than beneficiaries are now claiming.

On one of my largest projects, a slew of such concerns came at us from the beneficiary community. I offered them access to our test environment well in advance of production dates, even though we were pretty certain that the perceived risk far exceeded the likely outcome. You should always take this approach, even though the customer may throw the ball back in your court. In this case, the beneficiaries countered that, due to other tasks at hand, they would be unable to assign adequate resource for testing until the last minute. Naturally, we could not force them into such a short window, given the time of year and nature of their data processing responsibilities. As a result, we had to back off from some of the technology upgrades we had been planning to perform on their behalf.

Notice the wording of the last sentence, which said "perform on their behalf," not "perform at their request." From their point of view, these upgrades were being imposed on them in a way that made the risk too burdensome for their BAU processes. They did not care to fund additional resources to mitigate these risks up front. In this case, appropriate testing was not something we could do in proxy for them.