My highschool had some strange teachers: one, a geography teacher, genuinely believed the moon to be larger than the Sun; another, whose name and image are as clear to me today as they were then, got herself fired for wearing exessively short skirts and necking with a student. Sadly, that wasn't me; but the one lesson I should have paid more attention to, but didn't, was administered by a Doctor Johnson - whose introductory calculus course I managed to flunk several times over the same issue.
She would set exam questions that were mostly trivial - you could (and I did) look at them, write out the governing equation, step through the appropriate transform, and pop out the expected result -symbolic or numeric as appropriate. The problem was, she didn't see things that way: her goal was always process, never result; so I'd get zero marks for the right result while others would put thirty lines of garbage culminating in an absurdity and get 90% of the marks for "understanding" the process.
Drove me nuts.
Still does too -and this comes up all the time in assurance work where results are nothing and process is everything.
Look at any auditor's report on company financials and you'll notice they never say that the numbers are right: they attest to the integrity of the processes used to derive the numbers, not the values shown. A CFO who hasn't the first clue about the integrity of his systems can sign off on Sorbanes-Oxley because his internal audit people tell him the appropriate controls are in place.
The explicit premise is that the right process has to produce the right result - but sixty years of of business failures in companies getting big name auditors to sign-off on their financial reports should suggest that either billions of dollars in expertise and effort haven't produced a workable process, or there's something wrong with the underlying logic.
What's wrong with the logic is its implicit premise: that the right process is known with certainty, and consequently that the rightness of the process outweighs the wrongness of the result. This, I argued then and still think now, is positively ptolemaic in its refutation of the fundamental basis of science: that knowable things are verifable by repeated experiment - in other words, that results count.
Look at the range of audit types and IT audits stand out as the worst of worst in their disregard for result: cheerfully defying the lessons of science to discredit repeated failure as a source of information. The focus on process uber alles, imposes a disconnect between paperwork and reality: meaning that an IT manager can get the equivelent of an A+ grade from a CISA style IT audit almost entirely on the basis of paperwork - while actually doing such a poor job of running IT that nobody knows what orders are really outstanding, day to day financial operations are run from the bank statements, and finance clerks routinely get 50% of their take home pay from overtime associated with slow systems response, repeated data entry, waiting for systems or file recovery, or correcting for lost or duplicated data.
Look at the most intensively scrutinized IT projects - things like the IRS or FAA systems upgrades in the U.S. or Canada's multi-billion dollar gun registry fiasco - and you might almost start to believe that there's a relationship between audits and failures that goes beyond the obvious parallelism that most IT projects get audited and most IT projects fail. Indeed what I think happens is that the skills needed to survive audits are process based and tend to drive out the skills needed to deliver results. Dr. Johnson, after all, gave her least gifted students the highest marks.
Look closely at a typical IT audit today and what you usually see has two main parts: there's a paperwork based controls review modelled on, or implementing, the CoBiT standard, and a PC style "security" test that's nominally aimed at verifying control effectiveness but is usually just an excercise in mutual futility.
The CoBit standard is the gold standard for data processing governance - and I mean precisely that, because it doesn't apply at all to science based computing. Take a 1920s data processing center and change the technology but not the goals, methods, or organizational structures to accomodate the use of computers, and what you get is a data processing operation - to which process controls like service level agreements, role separation, and organizational blocks separating disaster, resource, and personnel planning functions are wholly applicable.
Replace that conceptualization with a science based computing paradigm built around user control, integrated applications and data, and the use of computers to facilitate n-way information exchange across time and distance, and essentially none of this stuff applies.
Bottom line: the service level agreement is the fundamental data processing control; essentially a peace treaty in an us versus them environment in which users are seen as supplicants whose needs are leveraged against budgetary change once the fundamental reporting role is fullfilled. Adopt the community philosophy implicit in Unix, empower your sysadmins to act directly for users, and that us versus them environment won't exist - meaning that the service level agreement won't make sense.
Unfortunately one side effect of Sorbanes-Oxley has been to empower auditors - often without the first clue about how systems work- to enforce data processing controls whether they apply or not. As a result we're now seeing an increasing number of cases where SOX compliance requirements are leading CFOs and other senior executives to distort the evolution of systems services, which had been trending away from process controls and towards results based management, by re-imposing organizational structures from the data processing days.
That gives the senior managers driving this the warm fuzzies as they sign off on their SOX obligations, but cripples IT's ability to focus on business needs, respond to external change, react to user needs, or take advantage of new technologies.
So what can you do? It depends a bit on your IT role. The more senior you are, the more exposure you will have had to process control demands coming from the CFO and his name brand SOX consultants over the last year or two; but this is the year the first of the pigeons will come to roost: the year the disjunction between process and result will get wider and more costly than it's ever been before. I never got anywhere arguing with Dr. Johnson's brain dead marking assistants, and you won't either if you simply paraphrase a particularly nasty political slogan to say that "it's the results, Stupid!" But that's the truth; and those results, particularly in terms of cost escalation and user unhappiness, could give you the leverage to reverse some of this next year if you can establish some less process focused projects now that demonstrate much better results.