% fortune -ae paul murphy

Be it resolved: project approvals

In a formal debate someone sets a question in terms of a resolution: Be it resolved that [something]; debate teams take opposing views of the resolution, and start arguing their sides.

With that mind I'd like to pose a bunch of management issues as resolutions, sketch out some arguments for one side, and see who wants to pick up the gauntlet - starting with one inspired by a talkback contribution from last week which I can't find right now because talkbacks are down again.

Therefore: be it resolved that no user requested IT project which the developer, his peers, and his immediate supervisor agree is likely to have positive consequences and will take less total work time to complete than the project approval process for comparably scaled projects, should need no further management approval.

In other words: if you work in IT, a user asks you to provide a function that's within your ability and role to deliver, your peers and immediate boss agree that this would have value, and you figure that it'll take less time to get it done than to get it approved, then you should just go ahead and do it.

As a control your boss will, of course, pass information about what you're doing both up and across the hierarchy - meaning that if it contradicts someone else's work or grand strategy, that problem will be caught and you therefore risk having to throw some work away after explaining the conflict to the user.

The most basic argument for this is simply that just doing jobs like these requires fewer corporate resources in total than evaluating all of them and then acting on some of them.

A more subtle argument is that actual usage is a market oriented test of the goodness or value of a development idea - and that bad ideas will die from disuse while good ones will prosper in user hands. Bottom line: just making it work is not only cheaper, but also produces better decisions.

The real killer argument, however, is that IT works for users: and acting directly on user requests reinforces that reality for everybody, where stepping user requests through an approval process does the opposite by blurring organisational lines to set up power conflicts both between IT and users and between user hierarchies involved in that approval process.


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.