Thursday, April 10, 2014

A WARNING for Project Managers of software development projects

I had a conversation with a friend last night and he was telling me about how an acquaintance of his, a project manager, had to watch the development team like a hawk to ensure that they delivered on time.  If you work on technology projects you have likely seen this behavior before, and in my mind this is a dangerous game.

To understand why we need to go back in time to when we were kids.  As a child my bedroom was always a mess and I'm sure that I'm not alone on that.  And every couple of months my Mom would tell me, "you aren't leaving your room until it is clean".  If you had a messy room too you can probably guess what I did.  Sure, I might have put a few of my toys on the shelf where they belonged, but at least half of the junk on my floor would end up getting shoved under the bed or in the closet.  About half an hour later I would proclaim, "my room is clean!"  But was it really?  Of course the first thing my mother did was look under the bed and in the closet.

Now I have a question for you.  When you are snapping at your team to pick up the pace to meet a deadline, are you looking under the bed and in the closet?  Many software project managers aren't programmers themselves, so they have no way of knowing if the product is good, or even what "good" means.  All the PM knows is if it is "done" or it isn't.

As a PM you you should ease up the reigns and realize that you are an equal member of the team, and not the "boss".  You have a role like everyone else, and it isn't your place to crack the whip.  It is a "team" effort.  Instead it is your job to work with your partners and solicit honest feedback about the quality and maintainability of the product being delivered, and the team isn't going to be honest with you if you act like the "boss".

If you have been a project manager for some time you should look back at all of those software projects you worked on perform a mental recap.  For each of those projects you should ask yourself the following questions.  Are the users of that product happy about using it, or does everyone grumble when they hear it's name?  Are the people maintaining the product happy with it, or are they constantly trying to fix it?  Was the project a true success and did it end up meeting the needs that it was designed for?

Software quality is at least as important as meeting deadlines so make sure that you account for it.

No comments: