Zarar Siddiqi's Blog

Developer thinks he'll make a better PM

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 pmi.org. 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.

Comments

• I've found a typical problem that PMs, business clients, and developers fail to deliver true usable items as milestones. We typically have milestones but they're usually half-baked with lots of problems. A true milestone component or set of component should stand on its own and more then just pretty pictures. They then explain away that we'll reach the real version by the end but the problems don't go away and can multiply as in your communication example.

  Posted by: smartinumcp on November 09, 2005 at 05:44 AM

• When Project Managers budget on the assumption that the organization will have 100% efficient communication, they set themselves up for the blame game. Time spent assigning fault for misinterpreting a requirements document is time lost to do something worth while. There are numerous points of failure when translating a problem domain to software. A good PM budgets for this, but a mediocre PM blames people because the obvious corollary is that he is accountable for not planning appropriately.

  Posted by: duanegran on November 09, 2005 at 07:58 AM

• This is absolutely true based on my experience. It's very frustrating as a developer to work on requests/enhacements for weeks and after demoing later to the the PM, he tells you that you got it all wrong. After listening to what he wants, soon you realized that you got communication problem due to technical terminologies that both of you don't agree...

  Posted by: ming_y on November 09, 2005 at 06:58 PM

• One of the contributing factors of this is that we tend to ask questions only when we think we don't understand. As soon as we've "got it", we go back to our desk and start hacking. I usually try to keep asking questions even AFTER I believe I understand, questions that will confirm that what I understand is actually what's going on. I sometimes even then go away, write a document about what I understand, and have the PM read and comment on it before I start anything. It might take a few extra hours, but it can save days or weeks of wasted work.

  Posted by: grlea on November 09, 2005 at 08:23 PM

• Yes, it happens, see Dilbert :-) Now, why does it happen ?

  I believe the most important fault is to view software as something like a sea of code, after all you can move water quite quickly from one side to the other, it still remains a sea of code. Unfortunately it is not like this, it is a building, with foundation, walls, doors, wiring and so on.
  Managers, developers, customers do not see a building, they think that ALL requirements can be changed and any of the change has the same impact on the project. But it is very different if we ask to change color to a room than to move a wall.
  It is possible and surely beneficial to build a CAD with basic building blocks like walls, doors, windows, wiring, foundations, where on each element you put specification, during the usual specification requirements different definitions will be put into different elements.
  The customer will be able to see at a glance what is a wall specification and what is just a color of a room.
  Of course.... this imply that the Project Manager know what he is talking about, not always the case

  Posted by: dbolla on November 09, 2005 at 10:40 PM

• A problem I've frequently encountered is that many non-programmers do not understand that programming demands more than a shopping list of requirements. This is, in my experience, particularly true of public sector projects. When developers try to engage the target audience for their application with a list of enquiries (eg: "how do you want the front end to look and respond?") you are often met with indifference and a general attitude of "you're the technical guy, you figure it out".

  Yet such questions are key to how a project will be written and what technologies will be in play - in the above example it will make the difference between a simple web interface, an AJAX interface, Flash, Web Start or even a full-blown desktop application.

  All too often I've been on projects in which key decisions have been resolved via a trial-and-error 'show them something and try to decipher their nit-pickings'. And all because the target audience won't spend a little time to engage with the developers, learn a little about the pros and cons of different solutions, and help to make a decision.

  After all, if you were building your own home you'd invest time to educate yourself a little, so you could work with the architect to get the house you wanted. But when it comes to computer software people switch off and throw a lot of the responsibility onto the developers. I guess software costruction isn't as sexy as bricks-and-mortar construction!

  Posted by: javakiddy on November 10, 2005 at 03:53 AM

• Interesting article, here are my thoughts on the matter.
  The relationship between Developers and Project Managers
  

  Posted by: davidhayes on November 10, 2005 at 05:53 AM

This work is licensed under a Creative Commons License.