Truth, lies and RFPs - request for proposals - Inside Apps - Industry Trend or Event - Column

Software Magazine, May, 1997 by Joshua M. Greenbaum

Why is it so hard to get a big software project off the ground? The most commonly cited reasons are bad software, bad management or bad luck. The product doesn't perform or the implementors don't know what they're doing. The managers change their mind, or run out of money. The company -- vendor or customer -- is sold off and the project disappears in the ensuing merger mess.

One of the biggest causes of software implementation failures actually occurs well before any of these other problems begin to have an impact. It's the most insidious, destructive force in all of software development, and the one that's the hardest to combat. I call it the "Big Lie" and it's written all over requests for proposals and the responses to those RFPs. And chances are, it causes more projects to fail than any other single factor.

I recently saw the Big Lie rearing its head in an RFP that started like this: "The business rationales for IT change at Company X are greater efficiency in overall IT processes, and a greater syn- chronization of functionality between business requirements and IT services." Too often the terms "efficiency" and "synchronization" are the first elements in the Big Lie. What's really going on is a major management disaster inside Company X: The IS and business sides can't or don't understand each other. There's a war underway, and the RFP is using business-speak to cover up the mess.

The RFP continues: "The Joint Architecture Committee has agreed upon a standard hardware and software architecture that will best serve the require- ments for growth and expansion in the IT arena." Translation: After two years of infighting and turf wars, the committee has come up with an architecture that pleases no one. But management requires that a change be made, so, by Jove, there will be change. Still, there's only the appearance of consensus -- in reality, pet projects and entire fiefdoms have been laid to waste in the process, and this company houses some angry people.

There's more. "The responding vendor will rank its proposed solution according to how well the vendor can satisfy Company X's requirements in three areas: IT requirements, line-of-business requirements and enterprise requirements." We're in the middle of a range war and the unsuspecting vendor is about to be blindsided by the politics of technological change. The project is imperiled before it even begins. Imagine what happens when implementation gets underway.

What's illustrated by this RFP is a problem that is played out at every level of business and technology change. When something needs to be improved, the simplistic approach is to make technological or structural change, despite the overwhelming need for political and cultural change as well. A company that needs a new IT system doesn't just need new hardware and software, it needs new ways of working, doing business, getting the job done. The employees need new job definitions, new hierarchies, new responsibilities. The company needs a big- picture approach to problem solving, not just a technological band-aid. But when it comes time to write the RFP, it all sounds so simple: We've got a technological/business problem, and we need a new solution. No matter that our internal functions are a mess, our departmental relations a disaster, our leadership running scared. Just give us new technology, and all will be for the best in this best of all possible worlds.

Imagine what happens to the vendors who walk into this trap. They innocently respond to an RFP that says not a word about the real organizational problems, try to deliver the software, and then watch as the mess begins to unravel. Some vendors, confronted with such a truly dys- functional corporate body, reap huge profits on the ad hoc redesigns that will come as consensus building efforts start all over again. Others find their reputations sullied by their inability to fulfill an RFP that simply didn't reveal the truth. In the end, there are rarely any winners, only survivors.

Solving the Big Lie problem takes a little more bravery than perhaps most organizations possess. But it's worth a try. The first step is for the user organization to manage the change process better. A consensus is hard to reach, but there's no substitute. If it can't be achieved internally, call in an outside arbitrator. Third-party advice costs a lot less than a failed IT project does. In step two, make sure that the real issues of political and cultural change are addressed upfront. Technol-ogy change by itself isn't enough. In step three, if all else has failed, go back to step one. The rule of thumb for software success is that it's always cheaper to send in the diplomats than the army. And anything is cheaper than telling lies.