The Many-Headed Beast on the Three-Legged Stool

Within a given organization — corporate or governmental — three separate groups exist that can determine the success or failure of your IT project. This is true whether you’re a senior IT project manager within that organization, a consulting firm developing or re-engineering a system for that organization or an external vendor trying to sell an existing IT product into that organization.

Those three groups include: the executive(s) who authorizes funds for the new system; the MIS group that will maintain and support the system once it’s in production; and the end users who will actually work with the new system. Make no mistake — any one of those groups can kill your project before it even gets started or turn it into a failure after the fact.

For obvious reasons, we tend to focus on the first group, those who control the purse strings. Without money, the project can’t start or continue, invoices don’t get paid and licensing agreements don’t get signed. But in exchange for that money, this group expects any or all of the following results from the new system:

• If the new system is replacing an existing system, then the new system carries out all the critical functions of the old system, has a longer lifetime, and shows improvements in functionality, reliability and performance.
• The new system offers new functionality that allows the organization to continue to compete with — or better yet, surpass — its competitors.
• The new system offers savings to the organization such as reduced support costs, increased efficiencies, reduced head count and increased productivity.
• The new system causes the executive(s) sponsoring it to increase in prestige, rank, authority and salary within the organization.

Needless to say, you must aggressively and repeatedly manage those expectations, preferably in writing. There’s not much you can do for the fourth set of expectations, but you certainly need to be aware of them.

The second group, MIS, may lack the economic power of the executives, but they can certainly put up a stiff fight against the development and deployment of a new IT system. Production support for the new system will likely come out of their budget and staff, so unless they see real advantages from the new system — as well as a commensurate increase in their budget and staff — they’re not going to be very happy about it.

You may assume that they’ll be happy to replace the old system (if one is being replaced), but you might wrong. The old system is likely very stable, or at the very least, it’s a well-known and well-documented system. And MIS probably has a few people who are very good at maintaining it.

By contrast, your new system is an unknown quantity. If it has just been developed — internally or by an outside firm — it probably has far more defects than the old system, many of which have not yet been detected. Interfaces with other internal systems will have to be set up and debugged. Both the new and the old system may have to run in parallel for a while, both as a safeguard against problems and as a way of ensuring that the new system gives identical (or more correct) answers than the old system.

The new system may also have a ripple effect in the organization’s information systems. It may require upgrades or changes to existing hardware, operating systems, and other custom and commercial systems currently in use. It may also call for wholesale conversion of existing databases and files, which can be a long, tedious, and error-prone process itself.

Finally, there’s a good chance that upper management — including the executive(s) funding the project — lack the technical background to distinguish between your technical arguments in favor of the system and MIS’s technical arguments against it. Machiavelli’s Caution comes into play here, so recognize that you have an uphill battle if you haven’t already got MIS on your side.

The third group, end users, has the least apparent power. But nevertheless, these users can sink a new project, too. They do this simply by complaining (rightly or wrongly) that the new system is unusable, less efficient, error-prone and lacking the hoped-for advantages that led the executives to fund it in the first place.

At least three major factors are at work in the resistance from end users regarding the new system. First, people don’t like change unless the advantages are blindingly obvious and the self-gratification relatively immediate. This is especially true for computer applications with user interfaces. Anyone who has lived through an organizational switch in the past 20 years from, say, WordPerfect to Microsoft Word knows what this is like and how bitter the fights can be.

Second, a replacement of an old system or the introduction of a brand new one usually involves a corresponding change in existing business processes. It’s not just the software that’s affected; there can be an impact on the way people within the organization accomplish certain tasks, even if they never use the software themselves.

Third, the people who are going to use the new system want to feel that they have a say in it. This may seem like an obvious step. However, organizations often purchase, develop or deploy new systems with minimum end-user involvement.

Keep all of this in mind when you embark on developing or selling a new system. It’s important to have support not only from the executives paying for it, but also from MIS and the end users as well. Without firm support from all three legs of the stool, the many-headed beast — aka your new system — will surely fall down.

[Adapted from an article originally published in Baseline. Note that this post has the original and correct title, which I stole from a talk by Dr. Robert P. Burton to the BYU Honors Society back in the 1970s; the Baseline title change was made without my approval and actually makes no sense.]

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.