% fortune -ae paul murphy

A class of dangerous project proposals

From chapter 2.2.1 - And, furthermore

This is the eighth excerpt from the first book in the Defen series: The Board Member's IT Brief.

(Last week's excerpt set out the nine common, technology free, indicators of a project that represents a systems disaster in the making and advised that board members simply vote against any project proposal featuring at least one of these indicators.)

There is an exception you need to be aware of: the perfectly legitimate project with every chance of succeeding - but whose success will hurt the organization as a whole.

You see this kind of thing in big organizations - DOD agencies, state or provincial governments, Fortune 1000 companies - anywhere many of the players have long memories and deeply entrenched positions. What happens in them is that one group sets out to build or implement a system that gives them a local advantage with respect to organizational budget and control issues or even legitimately with respect to whatever their mandate is, but at someone else's expense.

The classic example of the first kind of project is something like a government wide network proposal ostensibly aimed at saving money by implementing standardized technologies and centralized administration. Such goals are laudable and projects like this can have a good chance at meeting their budgets and goals - but you need to look beyond the bought consulting report usually offered in support to see how the reality would affect the budgets and scope of control open to the non proposing groups the heros of the piece are offering to serve.

Are these units, in fact, going to be paying the piper through things like higher internal transfer payments? decreased service levels? forced migrations from existing technologies? limitations on their freedom to work with people and technologies not blessed by the proposing authority?

The classic example of the second kind of project involves global or other application solutions. In these, one organizational division or group says it wants to pilot the application and will supply the service to other groups. Again, the project may have every chance of meeting expectations for the proposer, but be against the best interests of the organization as a whole because it forces other divisions or groups to take actions that produce net losses to the organization.

In general, applications that can be usefully shared across the organization offer cost savings opportunities and should be investigated. In the particular case of integrated science based applications, like ERP/SCM, for example, it is only through use of a single organization wide database that the key benefits of system wide optimization and executive access to data can be obtained.

In many cases, however, this generalization is used to sell bad ideas -and you, as a board member, need to be aware of this. To my knowledge there is no hard and fast rule that will let you differentiate good from bad when confronting organization wide change proposals emanating from internal groups offering to serve others - but there is one indicator I rather like. This is simply more often right than wrong, not a fixed rule; but: if the implementation would lead to a significant transfer of decision making power from other affected groups to the proposer, then it's probably a bad idea.

Some notes:

  1. These excerpts don't include footnotes and most illustrations have been dropped as simply too hard to insert correctly. (The wordpress html "editor" as used here enables a limited html subset and is implemented to force frustrations like the CPM line delimiters from MS-DOS).

  2. The feedback I'm looking for is what you guys do best: call me on mistakes, add thoughts/corrections on stuff I've missed or gotten wrong, and generally help make the thing better.

  3. When I make changes suggested in the comments, I make those changes only in the original, not in the excerpts reproduced here.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.