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.
My boss is a bit clueless like that. Every time I have to work on multiple projects and ask which one to give priority to, the answer is the same. All of them. He also insists that I should work on them simultaneously. Little bit of this, little bit of that.
Last time he suggested this I sent him a link to Spolsky’s article on how bad an idea multitasking is in software projects. I have no idea if he ever read it.
My god, thats fucked.
DOA- thats not *a bit clueless*, thats utterly stupid.
The managers usually know very little about whats involved in a project, they seem to just dump a new idea in the lap of thier underlings and expect them to make it happen.
How do such dithering idiots ever get promoted beyond toilet scrubbing???
You ever thought the problem might be you ?Maybe you have expectations that are too high ! Most people just want to pass their annual performance review and get a pay rise, not make lasting change and improvement. Nobody’s ever in a job long enough these days to care about 5 years from now.
Sounds like some of the companies I’ve worked for, though they usually didn’t limit the incompetence to scheduling.
For example: I worked for a company that designed and built rockets. My job was to write test procedures and help test RF components that came in. One part that ended up failing more than 50% of the time was a transmitter we used in pretty much every rocket. I asked the lead about it and he said he knew they were problem parts and actually spent every other week at the vendor yelling at them to fix the problems that kept showing up. I asked him, “So if we know their parts are usually bad and they won’t fix their design, why don’t we look for another part?” His response: “I tried that. Our bosses decided it would cost more to qualify a new part than to keep getting these fixed and keep flying out to yell at the vendor.” Silly me, thinking the customers might prefer that we get parts that, I don’t know, worked?
As ever, another great article.
I like to think of the difference between the approach you’re looking for in the story and the example the boss is taking as the difference between science and religion.
You both believe in the same thing (delivering the project) but you want to do it as a science and work out what you need to do to make it all work and the boss just ‘knows’ that if you pray hard enough you’ll get what you want. Say hallelujah!
It’s really hard work to push this with a manager when you actually agree with the goal but you want to quantify it. Any ‘attack’ on their ‘religion’ makes them think you disagree with the goal and earns you a 3 hour lecture on why it’s a good thing to do the project at all.
Which is really fucking annoying when was actually your idea in the first place and you’re simply trying to make sure that everyone is agreed on the same realistic objectives.
Ahhh, realistic objectives-the thing that many people dont know about or think if they wave thier magic fairy wand things will just happen.
Mike: Ask him about the procedure to get new parts qualified. Find out why it is so expensive and time consuming. Ask him what procedures you have in place to make sure that you only qualify vendors who can deliver quality parts since obviously the process for qualifying them is too expensive to do twice. See if you can find a way to qualify the parts that is cheaper or faster.
DOA: I’ve actually given presentations based on Spolsky article – it kinda worked.
Simon: It sounded like a walking Dilbert cartoon to me
Matt: The problem is always me and my damn expectations!
Mike: I am sooooo glad I don’t actually have to build things
Rob: Nicely put – science vs religion! If you don’t mind I’m going to steal that.
Simon: Why do they give those damn fairy wands out at management schools?
Soft_guy: Hmmmm, logic and commonsense – I like your optimism!
Every time I mention a classic book (“TMMM”, “Peopleware”, etc.) to a programmer or a manager, their reaction convinces me more and more that I’m living in an illusory world of my own…
Vladimir, I’ve read those books myself, pushed them on the people I’ve mentored, and everyone I’ve seen read them comes out better for it. I’ve never met a person “above” me on the corporate ladder that has read them, despite hints that they should.
There’s probably a moral in that (possibly “Rob: stop working for dysfunctional bosses”).
Mr Angry: by all means, go to town on the science vs. religion thing! I think it pervades a lot of what we all do here. Taking from an area I work in a lot, it explains about 90% of IT security cockups for a start. Or any programming project where someone introduced a framework because it’s “better” but can’t explain why changing everything over to it benefits the actual project itself: dare I say religion on rails?
this is the exact thing that made me raise my consulting rates from $125 t0 $250 an hour and then to $350 an hour. If I have to put up with your moronic idiot lines of thinking while I am trying to help you out then I want to get paid for it.
Vladimir: just like the rest of us, you are living in an illusory world of your own.
To get a bit of a handle on this, read “The User Illusion” by Tor Nørretranders, q.g.
This I remember reading the “Mythical Man” in grad school: there is no “silver bullet”.
‘Bosses’ and ‘qualifications’ are not always linked – clearly.
Hello there from the USA, Mr. Angry
G’day and cheers and some healthy vegemite 🙂
Nazli
Vlad: You mean the world where things make sense?
Rob: look for my “religion vs science” post soon!
AC: Good for you – if they pay you should take it!
Mayson: Is it the Matrix?
Nazli: So nice to hear from you again. I find it disturbing how rarely bosses and competence are linked!
This is just soo funny and to the point on PM – and yes PHB’s are morons, most are managers coz they really suck as techs.
Maybe the line “..He was promoted to the level of his incompetence..” could be worked into a future rant hehehe
The TMMM should be required reading for any tech foolish enough to consider going into management.
The story reminds me of this govt accounts software upgrade where they just keep appointing policy drones and consultants, but never good techs, even when the project really starts getting delayed.
I’ll see your Project Management nightmares and raise you *government* Project Management nightmares.
Classic example:
Me: “To make LEAN working pay off, you have to throw money at it from the outset and not specify how much you want it to save you in the long term. You also have to accept that it will take its own time, which you cannot specify or control. It will save what it will save you, and it will take however long it takes. That is how LEAN works. You cannot run it any other way.”
Senior Civil Servant: “Well, we’re prepared to budget £5Million to implement it, and we want it in place for 2009.”
Me: “Did you listen at all to what I just said? Do you even speak English? Wait, is this a recorded message I’m talking to here? What the fuck?!”
There’s no retard like a government retard, my friend.
supag33k: It seems as if you can deny the obvious, you’re management material.
custador: Nothing quite like a bureacracy heavy government project for creating a total disaster.
Pingback: Round-up - Someone Else
I often tell clients that they should worry less about project management and spend more time worrying about their software release process. Typically in my situation its been using a sledgehammer for a hammer or an antequated software configuration management solution that forces you into one process or another with developers complaining it’s keeping them from getting their jobs done. I was tired of excuses and brought in Accurev. We have more visibility and flexibility now than we did in 8 years with another tool I won’t mention. Start at the source, and work your way up to more project related metric issues. You will stop the leak and the pain.
Good luck,
D
Most of you guys seem pretty pissed at the whole PM situation which I admit can get pretty shitty sometimes, but what do u think about actually using PM Software programmes?
There are some pretty good ones out there, but there are some pretty bad ones too.
J
Jake: I would say some software can be a good support to the right people and processes. But if you don’t have the right processes in place and the right people to run things, the idea that software will fix things is bullshit.
Another approach could be to treat the date as given, make a realistic inventory of everything that needs to be done, and make an estimate of how many developers you need.
So instead of having 5 developers to do the project in a year, get 25 developers from the start to do the project in 6 months.
Cheap, fast or good. Pick any two.
The PM may even like the idea, managing a big project is good for his ego.
I have to say Thijs what you say looks better in theory than I presume it would on a more practical level. It raises many diffulties in terms of progress ratios and funds going to waste because its not invested in the right places at the right time. As much as I hate to admit it, it is in fact all about timing.
But Mr Angry, you definitely raise a fair point. PM software is absolutely useless if the right PROCESSES arent in place everything fucks up, with the key word being Process. The best projects I have handled wouldnt have been half so succesful as they are because the right kind of processes werent installed to begin with.
Yet I find in my experience that habitual processing techniques and progress comes easily with using PM software. I think the effects of this are psychological, because the right kind of PM software includes and utilises everyone in the PM foodchain in an almost identical fashion. Call it corny, bull-fucking-shit, but its true.
Im not saying that by using PM software makes your project flawlessly perfect, but it comes pretty damn close, because problems can be identified much earlier in the game.
But ofcourse finding the right kind of PM software for the right project is another matter altogether.
Tijs: That approach falls down dead when you realise the number of hurdles you face, namely the impossibility of adding enough competent people quickly enough and the way communication gets bogged down when staff numbers go off. It’s the central lesson of The Mythical Man Month – adding people to a late project makes it later.
Jake: Only people who stand a chance of succeeding in the first place benefit from PM software. Sadly, it’s most often used in dysfunctional workplaces by clueless people who end up making things worse.
Mr Angry:
Must say you have a pretty low opinion of PM’s and PM sowftware. But tell me have you actually used them? I bet you used something really crap and have been put off since. Dont really blame you, there are some pretty crap ones out there.
I used basecamp once on one project, wasnt really sure what all the high commotion about basecamp was because i discovered it was not that great. It wasnt a complete waste of time, there were some good things about it. but it was a let down enough to put me off pm software for a while.
J
I respectfully disagree.
I like date driven projects because I can put 60+ hours per week on my timesheet. The more silly the deadline the more hours I write down. Management loves this and I so does my paycheck.
Cubemonkey: You have indeed mastered the art of flourishing under adversity
Pingback: PM’s and BA’s in the Trenches | IT Hire Wire
Some times the PM is bad because the client is worse, though. One of the projects I’ve worked on had the client not understanding that if they were going to force delivery at a given date, they were going to get bug-ridden crap.
On that note, “working” on Christmas Eve, or at 4am, produces no usable anything.
But I do have to agree with Angry against Jake; there are really shit PMs out there, and no amount of software will help a shit PM make a project work. By the same token, shit programmer + awesome IDE = garbage. Tools are only as good as the craftsman, not the other way around.
Pingback: The Blog Of Neves Reborn
2 things:
I’ll give you another reason why companies seeks contractors, they’re easy scapegoats. They happily take the blame for anything, and anyone from within organization is OK with blaming them (after all, they’re not anyone’s resources).
On the mythical man month, I’ve published an article summarizing the whole book, might be interesting for those who want to know more about it (without reading the whole book).
Pingback: IT Science vs. IT Religion. Again | It's always MY problem