Skip to main content

Developer thinks he'll make a better PM

Posted by zarar on November 8, 2005 at 12:03 PM PST

Although I've been a core developer for a significant part of my career, I do often come in contact with the business-types who drone on about requirements while the eager-to-please IT shop keeps saying yes to even the most unfathomable requests. After all the yes's have been nodded and all the necessary hands shaken, the Project Manager brings a steep pile of 8.5 x 11's to the developers along with a pat on the back and a confidence inspiring wink. Boo Yeah! The project has started.

A meeting is held by all parties involved only to be cut short by 12:00 PM and the ensuing two hour lunch break. The developers are left figuring what this stack of paper is trying to say. The front page is pretty clear, "Inventory Management System" it says. On the second page there's something about Java being a requirement. There's also a due date. They start working.

Fast forward to five months later. The stack of paper has a lot of writing on it. Lines have been scribbled and crossed out. Along with bits and pieces of scribble, you'll also find pepperoni stains and some fluids which can best be ascribed to coke spills. Lots of code has been written, some of it has even been tested. The programmers are feeling fairly confident, the PM has his ass covered, anything goes wrong, and he’s ready to play the blame game.

Guess what? Something does go wrong. Seriously wrong. Turns out something works the way it's not supposed to work. "No Problem" says the PM and says he can have it fixed by end-of-day. The developer is told of the "problem" and the expected fix date. The look on his face is priceless: "That's not a problem, I've made it that way just like you said", he pleads pointing at the greasy stack of paper. They both consult the stack, sure enough, he's right. He's done what he was asked to do.

The PM frowns, goes away, comes back half an hour later and says, "You've misunderstood the document, this is what it really means". The developer listens, frowns, frowns some more, consults the other developers who all frown. An hour later, they reach the agreement that the wording can mean more than one thing depending on the time of day and the salary you're making.

The PM has found somebody to blame.


It's incidents like these that motivated me to go back to class and take a couple Project Management courses via I'm almost through with the courses and have so far learnt that Project Management is simply common sense wrapped around acronyms, document formats and jargon. It really does sound very simple and sometimes quite bloated. Hey, did you know if you have 10 people on your project you have 45 communication channels? How did I arrive at that number? Why I simply applied the formula n(n-1)/2. That’s 45 different conversations between two people and thus a lot of room for miscommunication.

See what I mean? Someone wise once said, "common sense is not common". I agree.

More on the conclusion of this course.