Pushing for the right IT project solution

In my last post, I talked about some of the reasons why large organizations often reject the best solutions for a troubled IT project: fear, pride, budget, and the ever-present internal politics. This week, as promised, I will talk about what it takes to champion the right solution. I can’t guarantee that you’ll succeed, but you will have a better shot at it.

First, let me lead off with one of my favorite quotes, taken from The Prince by Niccolò Machiavelli:

And it ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions and lukewarm defenders in those who may do well under the new. (The Prince, Chapter VI)

If you don’t think that quote applies to organizational politics in general, and to large IT projects in particular, think again. Few efforts within an organization are more political than large IT projects because so many groups have direct or indirect interests in how it turns out. That includes: upper management; business managers who plan to leverage the new IT system; business managers who have no need of — or are even threatened by — the new IT system; end users (new or transitioned) of the new system; the MIS staff that will have to support the new system; the vendors (if any) involved in the old system; the vendors (if any) involved in the new system; the developers who are building the new system; and even all the developers who are not building the new system.

Think about all those groups within your organization, then go back and read the quote above again.

See what I mean?

So, if in the midst of all that turmoil, you honestly believe that the new IT system faces serious challenges and that you know at least in part what the solutions are — but the powers that be don’t want to use them — there are, in my experience, three things you need to do in order to accomplish this change: establish credibility; build consensus upwards; and prepare to be fired.

Establish Credibility

If possible, you must start this task before any problems arise, since you may lack the time and opportunity to do it once problems arise. You build credibility in several ways. Work hard and work with the team. Know what you’re talking about, technically and from a business perspective. Always be honest, especially when it means admitting you’re wrong or you just don’t know something.

With regards to what you feel is the “right” solution for a difficult IT problem, understand and acknowledge the pros and cons of all proposed solutions, not just yours. Be really sure that your solution is indeed the best one – not just the most interesting or convenient. In short, give people a reason why they should listen to you. That leads to the next step.

Build Consensus Upwards

Many years ago, in the middle of a difficult and protracted software development project, I found myself concerned over some key issues regarding technology and features. I felt I knew the right answers, but mine was a minority opinion. So I went to one person on the development team and talked with her about my proposed solution.

She didn’t necessarily agree, but I didn’t argue with her; I just stated my reasons and left it at that. I then went to another person on the development team and did the same thing. And so on. After going through the whole development team a few times, I started to hear member of the team discussing my solution with one another — and agreeing with it, while adding on their own improvements.

I then moved upward in the management chain, repeating the same process. By the time that the firm had to make a decision on this matter, consensus had built around the solution from bottom to top, and it was adopted.

Most importantly, it wasn’t seen as my solution, because it wasn’t. It had been shaped and modified in the process; tradeoffs had been made; improvements added; and it was now a solution that almost everyone bought into.

I then started talking with the engineering team on the next thing that needed to be changed.

Be Prepared to be Fired

About a decade ago, while I was at a software development conference, I attended a session on how to affect change within an organization. I don’t remember his name, but what he said was unforgettable: if you really want to bring about change in your organization, you have to go into work each day prepared to be fired.

Mind you, he was not advocating aggressiveness, foolhardiness, or confrontation — at least, not for its own sake. But his point was clear: unless you are willing to stand up and speak unpopular truths, even to the point of losing your job, you may not be able to change things at all. Why? Because at some point your choices may come down to just that: shut up or leave.

This takes more that just courage, though courage is important. It means quite literally having your ducks in a row so that if you are fired — or passed over for promotion, or reassigned to some corporate backwater — it’s not catastrophic for you.

Note that this applies just as much to consultants as to employees.

I have known (but not worked for) large IT consulting firms that have been less than honest in their dealings with their clients, because they are not willing to take the risk of having the engagement end and all those billable hours go away. I have also known (and worked for) consulting firms that have been consistently honest and direct with their clients about both the problems and the best solutions. The client doesn’t always accept the firm’s solution, at least not at first — but guess who the client usually comes back to when the project goes south?

Establish credibility; build consensus upwards; prepare to be fired (or dismissed). That’s what it will likely take to get the right solution to your troubled IT project put into place when you face resistance.

Good luck.

[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.