Tag Archives: project

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.”

24 Comments

Filed under Work

Project management disasters

Over more than 10 years of contracting as an IT Business Analyst, I’ve learned there are two main reasons companies hire contractors. Either they’re running some huge sprawling project and want to throw more bodies at it or they don’t have the in house expertise for a particular project so they want to bring in an outsider who does.
Although the big, sprawling projects are a major source of employment, I really don’t like working on them. The main reason for my dislike is that most of these massive projects are disasters. The company is trying to do too much with too little idea of how to do it. The classic nightmare for IT staff is to be stuck in a project that’s date driven.
By “date driven” I mean that the only way the project is measured is by whether or not is it delivered by some totally arbitrary date. It’s bad enough when you have to deal with a project manager who wants you to bow down before their Gantt chart as if it’s Holy Scripture. But I have actually worked on multi-million dollar projects where all activity is driven by the fact that someone in senior management has said it should be done by a certain date.
There’s nothing that fills a development team with horror quite so much as something along the lines of “the new financial system wil be in place before the end of the financial year.” And when you ask how that date was arrived at you get little more than “that should be enough time.” As an analyst I find that sort of crap particularly galling because people who think this is a good way to run a project usually get pissed off when I start actually doing my job.
They get pissed off because my job is to ask questions and arbitrarily set dates usually don’t hold up well to questioning. Here’s an approximation of fun conversations that happen on projects like this
BOSS: The project has to be completed by the end of the year
ME: What’s actually involved?
B: A new CRM system has to be installed. It will replace thee old stand alone systems and make us more efficient.
M: But what’s actually involved?
B: I just told you, we’re implementing a new CRM system.
M: But what has to happen for that to be installed? You said it’s replacing three existing systems, what happens to the data stored in those systems? There’s no way we’ll be lucky enough that the new system handles data exactly the same way. Can it be configured to handle existing data somehow or will that require programming changes? Or is that not even possible which means we’ll have to convert the existing data to a usable format? Can we do that via an automated process or will it have to be done manually? And what about other systems that had interfaces to the systems being replaced? How many interfaces to the new system are required and how long will it take to develop all of them? And what about the users? Have you checked that the new system can actually meet all of their requirements? Are they going to have to change any existing processes in order to use the new system? Have you allowed enough time for training? And how does it affect external suppliers?
(At about this point I can see the boss is making a mental note that I’m a troublemaker. I can see it in his eyes.)
B: We don’t know the answers to any of those questions but we’ve committed to meeting the delivery date. I’m sure if we all get on board and make a commitment as a team we can make it happen.
(At this point I’m making a mental note that the boss is a fucking moron. I hope he can’t see it in my eyes.)
M: But you haven’t even defined what “it” is. You made a commitment to deliver the project by a set date without even quantifying what work has to be performed. How can you possibly commit to a date when you don’t even know what you have to do?
B: If we discover that the volume of work is too much for the existing team to handle then we’ll add more people to the team.
M: Have you ever read “The Mythical Man Month”?
B: Never heard of it.
M: That doesn’t surprise me.
The book “The Mythical Man Month” was written more than 30 years ago by a manager at IBM. The single most important point in the book can be summarised as “adding people to a project that is already behind schedule will make it later”. The main reason for this is that the more people you add, the more convoluted lines of communication become until it gets to the point where communication takes more time than the work itself. There’s also the fact that when a project becomes severely behind schedule resourcing usually isn’t the main problem. An utter lack of direction from clueless management is usually the bigger issue.
 
Software development is one of the fastest changing industries in the world.  But even after 30 years this book is regarded as one of the fundamental classics in the field.  The author jokes that it is referred to as the software development “bible” because of the number of people who say they believe in it but don’t follow its teachings in their day to day life.
 
I have often considered bringing it in to work to show particularly clueless managers.  I think that maybe if I brought a really nice hard bound edition in, I might be able to beat them to death with it.  And then I realise why I’ve never moved into management. 
 
I like to be able to face myself in the mirror.

32 Comments

Filed under Work