PM Talks

by Pawel Brodzinski on September 3, 2008

I spend a lot of time with project managers. Heck, I sit with 4 of them in a room. I want it or not I see how they manage their projects and their project teams. I see how they talk with people.

Each of them does it differently. However there’s one thing which is common – there’s a distance between a PM and the rest of a team. People consider PM as a kind of boss. That has of course a bit of truth since PM is the person who manages the project and at least partially the project team. There’s another reason too. PM is usually a person connecting project team with a client, so he should know what client wants.

Now, PM can use this “power” to get what he wants. Change this interface because it has to be like that. Add this feature because it is crucial for the client. It won’t be accepted during tests. We have to do it different way because business requirements say so.

Each PM sometimes will go that way. Sometimes it’s just easier. Sometimes they don’t see any other way to get what they need.

My advice is: avoid that whenever you can.

If you’re a PM you probably have more knowledge about project than any single person in the team. But it doesn’t mean you always know better. It doesn’t mean you have more knowledge than all your team gathered in one place.

There’s a bunch of better options:

• Discuss. Tell why you think client won’t agree. Go deeper in the discussion. Today we went from trying to decide what columns we should add in the database to description how small vendors should craft their business offers for big clients. It happened during technical session with developers and I don’t consider that time as wasted.

• Listen. We tend to listen to only those arguments which support our opinion. When our position is stronger than our adversary it’s even easier. It’s more difficult to listen to others’ arguments and be ready to change one’s mind.

• Ask. With the distance PM has with the rest of the team sometimes it’s even hard to get someone’s opinion if you don’t ask. Hey, she runs a project so she knows better, right? Why should I throw in my ideas then?

• Delegate. Some decisions have to be made but it’s not a PM who is the best person to be a decision-maker. Programming details. Tools used in development. Approach to testing. The list is long. When the team expects you’ll have all the answers try to delegate finding some of them on others. When encouraged people will be more creative than you’d expect.

Remember, each time you use “I know it better” approach people will less likely participate in decision making process. You’ll end up in more “I know it better” decisions which are very rarely the best possible option.

Leave a Comment

Previous post:

Next post: