Religion vs. Science

I think I’ve discovered the secret of the long standing conflict between IT workers and management.  Which is to say, one of my commenters (RobMoir) articulated it and I’m totally stealing his concept.

 

It comes down to the same mentality as religion vs. science.

 

A true believer in religion doesn’t need proof, faith is enough for them.  In fact, a lack of faith and a desire to see empirical truth is seen as a severe failing of character by the faithful.  Conversely, a follower of science finds it difficult to conceive of how someone could simply not want to undertsand something.  The very act of surrendering to a higher power rather continuing the quest for knowledge is incomprehensible to the follower of science.

 

And that’s where the gap in managing IT projects seems to be.  Managers all too often seem to operate on principle of religious faith rather than responding to any objective reality.  The project plan becomes holy scripture.  Or worse still, management exhorts the team to operate on faith alone.  “If we all work together, we can meet the delivery date.”  Reality be damned.

 

A good IT worker treats a project more like science and asks pertinent questions.  What exactly will happen?  How will we make it happen?  Who specifically has the skills to make it happen?  What course of action will we follow when the unexpected inevitably happens?

 

Mind you, if you want to see an IT worker get religious, start up on their pet operating system / programming language / development methodology / technology platform and/or gaming system.  There’s nothing quite as fierce as a technology based holy war.

 

For an illustration I’ll provide another slightly dramatised discussion based on a very real experience from my (thankfully distant) past.  A bit of context first: I’m a Business Analyst (BA) but there are often two sorts of BAs.  One is based with a business unit and represents their interests.  This person usually writes a Business Requirements document.  The other is an IT based BA who looks at things from a systems basis.  This person is often called a Systems Analyst or Technical Analyst and writes a Functional Specification.

 

In my time, I have been both.  Sometimes on the same job.  In the following example, I was a Systems Analyst.  The BA from the business group was presenting their requirements document and wanted us (the IT group) to sign off.  This was the first time we has seen requirements from them.  And quite frankly, they were shit.  The best bits were ambiguous to the point of being useless and it was full of straight out errors.

 

The BA’s starting point was that me signing off their document was a foregone conclusion.  My starting point was that this was a review meeting.  If the document didn’t pass review it was going back for more work.  When we reached the critical point of “No, I’m not signing off on this piece of shit you call a requirements document,” the following discussion too place (translations provided for people who don’t understand polite business speak).

 

BA: But this meeting was to get a sign off.

(Translation: It’s inconceivable that you could doubt the Holy Scripture.)

 

ME: This meeting was to review the document, I can’t sign it of in its current state.

(Translation: I need proof, not blind faith.)

 

BA: But the project plan says we have to have this signed off today!

(Translation: The Divine Word from on high tell me it is so – I dare not question.)

ME: Then you should have had review sessions before today so we could have given you the feedback you needed to have it ready for signoff.

(Translation: We sign off requirements when they’re right.  We don’t sign off steaming piles of camel turn simply because an arbitrary date has been reached.)

BA: But to meet the schedule this has to be signed off today. We’re delivering it on schedule but you have to sign it off.

(Translation: The schedule said I had to produce a document by today.  I produced a document.  What could possibly be wrong?)

ME: We can only sign off on the requirements when they’re right, not when they schedule says they should be signed off.

(Translation: Was I not clear about the steaming camel turd?)

BA: Well, could you do a “conditional” signoff and we’ll make a note of your issues?

(Translation: If you’re stupid enough to put your name to this you’ll never see me again – it’s your problem from then on.)

ME: You’ve got my feedback, that’s all that’s coming out of this meeting.  There’s no way I can sign off on these requirements. Take the feedback to your manager and if he has any issues he can take it up with my manager because I’m under strict instructions to not sign off anything until it’s ready to be signed off no matter what the schedule says.

(Translation: We’re onto your little games.  Now get the fuck out of my face or I’ll jam that worthless document down your throat until you choke.)

Surprisingly enough, I did not extend my contract at that place.  The job market was very strong at the time and life is far too short to put up with that sort of insanity-inducing dysfunction.  Mind you, it did form the basis of my forthcoming thesis “Project Management Failure – an archetypal example of how to fuck things up completely.”

Advertisement