CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
 |
|
68% of all technology projects fail. |
Ever been on a project that is on the slow death march to failure? I have, more often than I care to remember. And, each of these projects had a Project Manager at the helm. These PMs were not evil. They just seemed to not know any better.
On the other hand, I have been on projects that were amazing. These projects were made up of competent people, having fun, and working in harmony toward a common, meaningful goal. These projects were led by Project Managers who had it down. They led. Their teams performed and their teams shipped. They totally did not suck.
So how do you totally not suck as an IT Project Manager? Well, from where I sit with a developer’s point of view, it comes down to the following 10 items:
1. Understand that Managing Is Not Bossing
If you find yourself bossing me around, it’s a pretty good sign that you can’t manage me. Management is about keeping the pathways open and the team fed—intellectually, emotionally, and gastronomically. It’s about inspiring people to do their best. It’s about making sure birthdays are celebrated and bagels show up on Friday mornings.
Bossing people around is a waste of time and karma. When you find yourself bossing me around as in “do your status report” or “get your coverage numbers up,” there is no management to be had. If I don’t have the basic habits necessary to work on a modern software development team, either find someone who can can inspire me, or get me off of the team and get someone in who has the habits required.
2. Understand that Agile Is a Whole Lot More than Daily Stand-ups
You’d be surprised how many VPs walk around and reassure themselves that if daily morning stand-ups are happening, then Agile is happening. We know otherwise. We know that Agile is a way of life in which stand-ups are but the tip of the iceberg. Unit testing, measuring velocity, backlog management, self-directed teams: These are just a few of the things that are in the stew that is the Agile Methodology. Unless all the parts of Agile are in play, a stand-up is just another meeting. You can’t fool us. A stand-up may look like Agile, but it’s really just a meeting.
3. Be a PM Who Is Not Afraid of Being Fired
There is absolutely nothing that I find more distasteful than a Project Manager who is afraid to stand up to Management when unreasonable demands are being made. Yeah, we, all of us, have to pay the rent and many of us have to feed the kids. But, a Project Manager that lives in fear of being fired sucks. A project turns miserable when we’re always giving into unreasonable behavior on the part of management. Most companies want what they want, when they want it. We get that. But, we also know that many times a senior manager does not really know what he or she wants, other than to meet a date and keep another higher-up happy. So, they make little unreasonable demands that, after time, turn into larger unreasonable demands. And then the project becomes a Death March in which everybody quits on Ship Day. We admire a PM who will push back on unreasonable behavior with no fear of being fired. Every good Project Manager I know that has stood up and been fired; has had no problem finding another job.
4. Don’t Say, “I Am Not Technical, but…”
If you want my respect, show me concretely that you speak my language and understand my landscape. I expect you to be technical. Jeepers willikers, it’s IT, for crying out loud. You cannot manage a team if you don’t know the game. Would Yogi Berra say, “I don’t know baseball, but…?”
5. Don’t Listen to or Accept Techno-babble
When I am feeling anxious or irritated, I will go into techno-babble. Most times I want to obfuscate my own sense of inadequacy, play alpha-dog, or just make the world go away. So, I’ll use terms and concepts I think only cool developers know. If I do, call me on it. Okay, don’t do it in a meeting, causing me to lose face. Rather, take me aside afterward and ask for clarification. If I really know what I am talking about, I can explain my thinking on a whiteboard pretty quickly. If not, I am putting one over on you. Underneath it all, I know that everybody can’t know everything. Take away the audience and I am happy to tell you what’s going on.
6. Don’t Show Meaningless Numbers
Don’t show me a bunch of charts and tables that mean nothing to me. Show me simple, clear project numbers: burndown rate, passing unit test percentage, code coverage numbers, team velocity, and schedule. I expect that you have enough mastery of all the project metrics that you can talk to anybody about the project’s status in concrete, quantitative terms. From Upper Management or developer, I expect your numbers to be right always. I expect Upper Management to have complete faith in their accuracy. I just don’t need to see all the metrics or provide any that are outside my scope of activity. My job is to make code that rocks. Your job is to know your numbers.
7. Don’t Yell, Ever.
I will yell back and then we’ll both be known as drama heads. If I don’t yell back, be assured I will silently be plotting your demise.
8. Don’t Play the Dating Game
When my car is broken, I don’t go to my mechanic and say, “fix it by noon.” And, my mechanic, who is a really good mechanic, does not say to me, “would you take 3 PM?” He’s been working on cars a long time; I trust him enough to come up with a time by which my car will be repaired. I make arrangements to work around his schedule. I expect that when there is a problem with his ETA, that he will call me and let me know. He always does.
So, don’t come to me and tell me when my code is going to be delivered and don’t force me to counter with an alternate date to make you go away. I am the expert. Give me the time to come to an educated ETA. And, if I find I am slipping, I will let you know as soon as a problem comes up. If I do find that I am slipping and I do not let you know as soon as I can, I will understand when you fire me.
PS: I expect also that you will not make promises to Upper Management about dates without consulting with the team first to determine delivery dates that we all agree upon.
PPS: My mechanic’s name is Kenny.
9. Understand That It Is Not Someone Else’s Job to Take Notes; It’s Yours
When I sit in a meeting, I understand that I am there to make a contribution. If I am typing away on my laptop or cell phone, I am being rude and disrespectful. I probably know it, but I am testing you to how much you’ll tolerate. Feel free to call me on it politely.
On the other hand, my job is to not take notes of everything that gets covered. That’s your job. I will admire you if you bring someone else along to do note taking. I will think that you think ahead. If you ask me to take notes, I will think that you are lazy.
10. Don’t Create Surprises; Have Buffers or Contingencies
I hate being surprised unless the surprise ends up with me getting a lot of money. I have a life. I have lots of interests. I have family. My weekend and evening time is allocated already. Yeah, I know that sometimes extra work is required. I won’t get too irked if I have enough time to plan, at least a week in advance. And, make sure that asking for overtime is the exception, not the rule.
I know that project dates slip; they always have; they always will. The PMs whom I respect planned for slips and had time, money, and contingency plans in place to accommodate the delays.
Bonus Item: Don’t Do the Death March
Death March is when we are expected to work all the time, day and night, in miserable conditions, to meet a date that none of us agreed upon. When Death March starts, that’s when I call the recruiters and start to send out resumes. Death March is a sure sign of a PM who totally sucks. Don’t be a PM who totally sucks.
