Resistance to the right IT project solution
Over lunch some years back, Barry Glasco (a colleague) and I were reminiscing about corporate IT projects that we’d worked on as consultants over the years. Typically, these were large systems that were either having trouble being completed or were having serious problems once they were in production. Barry pointed out a self-defeating pitfall or anti-pattern that we had both seen in such cases.
The consultants, usually with the help of the employees in the trenches, would use their time, effort, and expertise to analyze the system under development or in production. They would arrive at a clear, supportable, essential solution — technical, architectural, methodological, organizational, whatever. This would be presented to upper management…whereupon upper (or project) management would say, “No, we can’t do that.”
Sometimes, management would give no specific reason why the solution was not acceptable. Sometimes, they made it clear that it wasn’t the solution they wanted or that they felt was acceptable. If they did explain their rejection, it was usually in budgetary or political terms.
The investigating team would often then go back and look for an alternate (and less optimal) solution. If one was found, often that was rejected as well, and so on, often down to the least desirable solution. Barry said that he and another colleague, Chuck McCorvey, had gone through this so many times with one client that they joked about simply presenting the worst solution first, since it seemed to be typically the only solution the client would accept.
Note that this is not always the case; I’ve seen situations where the client has accepted and implemented — as best they could — the ideal solution, usually with positive results. But the opposite happens often enough to raise the issue: why? Why does a corporation or government agency that is investing millions, tens of millions, or even hundreds of millions of dollars into a major IT system sometimes so resistant to solving its problems?
From my own observations, it usually boils down to three interrelated factors: internal politics; budget; and fear/pride.
Internal politics. Large internal IT systems are seldom the purview of a single group within an organization. Instead, they usually involve several different groups, each of which may or may not be all that happy about having to work with some of the others, but are forced to do so for various budgetary, departmental, or business alignment reasons. In many cases, the development effort itself — analysis, architecture, development, quality assurance — is split across these groups with resulting consequences. As Conway’s Law predicts, you often end up with a system with a truly Byzantine architecture, which may even be the reason the project is in trouble in the first place. The recommended solution is sometimes unpalatable to one or more of the groups involved — due to a loss of control, a loss of functionality, or a change in approach — and so they object to the solution.
Budget. This may seem counterintuitive, but management often finds it easier and safer to have a project drag on year after year, ultimately costing large sums of money, than to spend a relatively small (but still painful) fraction of that amount up front and fix the problems now. This is not to say that throwing vast sums of money at an IT project will necessarily fix it. A $1.5B (yes, that’s billion) internal IT re-engineering project that I reviewed (as an expert witness, not as a consultant) was spending for a period of time $750,000 a day on consultants in a vain attempt to circumvent Brooks’s Law. But often a key purchase of hardware, software, and/or services will help solve the problem — and that purchase is rejected as being “too expensive”, though in the end it turns out to have been far less expensive than the project’s continual delay or problems.
Fear/pride. Fear and pride can be closely related, particularly when the issue is admitting you made a mistake. This is particularly true if a key manager, architect, team leader, or developer has championed or defended a given approach that turns out not to have worked. We don’t tend to reward major mistakes within corporations — except, perhaps, at the CEO level — and so when a proposed solution is in conflict with the defended approach, or worse yet shows it to have been a major mistake in the first place, those with a vested interest in that original approach will often fight against the solution. Even if the original champion(s) acknowledge privately that the proposed solution makes sense, they may be afraid to admit it publicly for fear of losing status, influence, or even their employment.
Note that these barriers aren’t unique to situations when outside consultants are brought into a troubled project or system. IT project managers and engineers are often quite aware of the necessary solutions, but can’t get them accepted for exactly these same reasons. In the next post, I’ll talk about what you can do — as an engineer, manager, or consultant — to help the right solutions be implemented.
[Adapted from an article originally written for the online version of Baseline.]
About the Author: bfwebster
Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.