Project management disasters

Jump to Comments

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.

19 Comments

Filed under Work

Tags: development, management, project, software