Nine Destructive Project Manager Behaviours: Part 1 of 9

This is the beginning of a nine-part series on destructive behaviours project managers can exhibit that will inevitably hurt the project they’re supposed to control. It’s been great fun to work on, and I hope you have as good a time reading as I did writing it.

Each article is accompanied by a little indicator that is my subjective opinion on how damaging the behaviour is. Some may have only minor impacts; some may be severely destructive. In all cases PM’s behaviour will have a direct impact on the project under their care.

I’ve witnessed all of these behaviours first hand over my career (you may have too!), and even been guilty of some. It’s my hope through posting this that others will see what I see, and watch themselves for signs that they may be developing a destructive behaviour.

Without further ado, I give you the first of nine:

1. The Sack.

Sacks take delegation to a new level. Not content merely to intelligently assign work, Sacks are fully prepared to give away the project vision to someone they trust on their team. If they’re very lucky, the person they hand off to will be trained or have experience in project management – but unless the project budget supports two project managers, somebody’s getting shortchanged.

While Sacks are happy to give away many aspects of their project, they generally don’t like giving away any of their authority.

It’s important to note that Sacks are charged with managing their project directly. Sacks are not program managers or portfolio managers who have other concerns and are within their rights to delegate their project responsibilities to another. These are project managers who let themselves get carried along for the ride.

Consequences:

Because they’ve divorced themselves from the work, they have only the vaguest understanding of change impacts. They blithely accept any scope changes stakeholders ask for because Sacks have such little investment in the work breakdown structure. For this PM, there’s no reason to push back or ask questions and risk the short term friction.

I’ve rated Sacks “Dangerous” on the destructiveness scale because they’ve effectively cut the head off their own project. I would rate them higher but since the Sack’s people will carry him or her, projects often get done successfully in spite of the PM’s behaviour. Don’t be fooled.

The likelihood that the project team will want to work with the Sack again is pretty low. To compensate for the Sack’s abdication of responsibility, the project team has to organize themselves in such a way that they keep each other updated behind the scenes. They also have to forge their own relationships with stakeholders to make sure the PM doesn’t dump a bunch of misinterpreted requirements in their laps and create problems for them.

This won’t end well for the Sack, because the need to bypass him or her to get work done will eventually result in a message that the PM isn’t doing much of anything. If he or she survives to the end of the project, there will likely be a lot of questions about using a Sack again.

Prevention:

There’s a big difference between “delegating” and “washing one’s hands”. The project manager has to constantly arrange all the moving pieces of a project into a cohesive plan and vision. He or she has to keep that plan organized and focused on the outcome in the face of tremendous change. If the PM gives that job away to someone who only understands part of the picture, all the work outside the purview of the assignee is at risk.

Quite often the cause isn’t that the PM is lazy or autocratic (although that’s usually the perception). Projects are meant to create something new that didn’t exist before, at that company, for those people. They also cross boundaries between the business asking for the new product or service (the domain), and the developers who will create it. A person trained in project management often isn’t trained in the domain or the development.

That’s an awful lot of unknown for one person. If the project is especially complex, there can be a big temptation to sit back and let all those other people who seem to know what they’re doing handle all the heavy lifting. But those people are depending on the PM to keep the moving parts together. What’s the poor Sack to do?

1. Learn about your project. Talk to your people (and buy them a cup of coffee, cheapo). Understand what they do, at least from a high level. You’ll learn more in time; but you have to be patient. Rome wasn’t built in a day, and even you can’t process multiple careers’ worth of knowledge in your first week on the job.

That doesn’t mean you’re exempt from asking lots of questions though, right up to the last day of the project. My teams have often likened me to a five year old: “why is the sky blue? where do babies come from? what happens if I push this button? why are you staring at me?” I’m okay with that. 😉

The more you understand about the thing your team is creating, the better you’ll be able to steer your project around roadblocks.

2. Learn effective delegating techniques. Like many professional skills, there’s this big assumption that people know how to delegate out of the box. Let me settle this right now: good delegating is an art form and it’s hard. The idea is to assign enough work away from yourself that you’re free to do your job, while still being responsible for all of it. Here are some great articles on good delegation:

• Free Management Library
• Mind Tools
• Blog Business World
• Stress Management and Mind Tools

Assigning work effectively, staying on top of the work you’ve assigned, and maintaining active relationships with your team members will help prevent this behaviour from rearing its ugly head. And knowing you’ll live to work another day means the only Saks you have to worry about can be found on New York’s Fifth Avenue!

Next up: The Magpie

 

Related articles by Zemanta

• Entrepreneurs Need to Delegate Effectively (startupprofessionals.com)
• Time Management and Workplace Delegation (workplaceculture.suite101.com)
• How not to screw up an ERP implementation (go.theregister.com)
• How I Get Things Done – And How You Can Too (mt-soft.com.ar)
• 40 Ways to Build Trust on Your Project Team (edge.papercutpm.com)
• @Task Stream: A New Way to Communicate on Projects (edge.papercutpm.com)

This series has eight more articles coming your way! Don’t miss a single one!

I’d like to hear from you about this article. At the very top in the grey box are eight other destructive PM behaviours I could think of. But the list isn’t inclusive. Offer up other behaviours you think could be added to the list and if I get enough I’ll run another series featuring yours!