In IT, as in many knowledge fields, we try to plan ideal systems. Specifically, we aim to create systems approximating best practices or a theoretical model within the constraints of budget, time, and functionality. Accepting the three traditional constraints chafes, but as professionals, we learn to live with it. Sometimes, though, we encounter a fourth restraint, where the best practices or ideal model of one of our superiors contradicts what we know to be right. Whether we overcome these constraints or not, how we handle the effort could well determine the fate of our project.

I encountered this fourth constraint directly for the first time while working with a midsize client (around 1,000 nodes). The project itself posed few challenges. The client wanted to update its backbone mail servers and experiment with a handful of new workflow applications to streamline operations. The only exciting bit of the plan called for an interface with an existing legacy ERP through the mail system. The team was small enough for me to work as both project manager and senior architect with a split team of six, evenly divided between developers and engineers.

The first few months went by in the typical blur of activity. The team worked hard, doing good work for the most part. After the beta test and second pilot, everything looked on track for early delivery. Then I received an invitation to attend an emergency meeting with the CEO and other executive officers. I pulled together my TCO and project status information.

The meeting turned out poorly. Despite our cost savings data, the productivity gains promised by the new workflow applications, and improved availability, the CEO wanted to shut down the project. We were three weeks ahead of schedule by our estimates, but he pulled out a document from a year before the project started, saying we should have been done in four months rather than eight. He told me that I had a week to come up with an action plan or he would shut down the project permanently.

I made it back to my cube in a daze. Someone, somewhere, had executed a political end run around my project. But how? Who? And more importantly, why?

A difference in needs
The answer to my questions came in the form of a lunch invitation with the CIO. As we ate sandwiches, he laid out the situation for me.

As a side effect of our technology upgrade, we would install a much more effective data archive and retrieval system. The current system, mostly for procedural reasons, had difficulty retrieving any data more than a month old or a specific e-mail (or e-mail thread). The new system, as we had it laid out, would be able to store/retrieve up to six years of data with only a marginal additional cost. As a side benefit, we had streamlined the recovery and business continuance procedures to allow for sub-eight-hour response times on archive retrieval requests—all technically sound and done at very little cost to the client. These plans were, in fact, exactly the kind of thinking he paid us for.

Unfortunately for my project, the idea of storing that much company data, especially private exchanges, for any length of time made “one or more” of the executive board members nervous. They watched the news; they knew that subpoenaed e-mail would play a part in any litigation against the company. With the old system, they could present a plausible excuse for why the data simply could not be presented. Our new system exposed them to a possible threat.

I was stunned. As a project manager, I worry about failing to meet my client’s expectations, not exceeding them and being punished for it. Yet I could see their point. The current system did provide them with a shield, a way to hide their actions in the obscurity of time that our innovations on their behalf removed. In a conflict between my teams’ ideals and the ideal functions as seen by the people with the money, the money will eventually win out even if they have to give up functionality to do it.

The CIO went on to outline our options. As a team we could either close up the project or make the disaster recovery look extremely complex. The latter option would allow us to petition the board to remove it from the project, clearing the political path for us to move ahead. After we finished, I went back to my cubicle and thought long and hard about what to do.

A reversal in the usual change management experience
As I sat there pondering the fate of my project team, I realized this was not my first run-in with a difference between what I knew we could do and what the client thought we should do. Generally, I encountered this situation from the other direction: Clients had unrealistic expectations of our abilities, and I had to talk them into a realistic assessment of what they could get for their money.

Both cases stemmed from the same fundamental issue. Clients believed or knew certain things about IT. These beliefs colored their decision-making processes as well as their expectations about what we would do for them as part of our services.

Most of my clients shot for the stars. They want every function they can possibly imagine, under time and under budget. Changes come in fast and furious as they try to align the reality of the project with their evolving vision of what it should be.

This client took the opposite approach. For reasons of their own, the decision-makers wanted to shear away functions and were willing to cite an expansion of time/difficulty as the reason. They also engaged in blatant carrot-and-stick manipulation: If I did what I was told, my company kept the project. If I failed to do so, they would use a trumped-up reason to remove us and get a more biddable contractor. Looked at this way, the disaster could almost be counted as a blessing. How often do clients try to give you less work for the same pay?

What would you have done?
In the end, I passed the buck by calling my manager and then his manager. We decided to preserve the project rather than fight for something the client did not want. We kept six people employed for another four months, when they would otherwise have been let go because of a lack of projects. The client received most of the functionality they needed, minus the disaster recovery and data archiving capabilities we wanted to implement.

In a similar situation what decision would you make? Would you weigh the jobs of your people higher than ensuring the client received all possible functions? Where would you weigh in on the ethical conflict between proper system implementation and the client’s desires? At what point do you protect yourself and your team with deniability rather than stand up for what is “right?” Post a message to the discussion following this article and voice your opinion.