Project Management

The Problem with Project Management

From the pmStudent Blog
by
Ranting and raving about project management and systems engineering.

About this Blog

RSS

Recent Posts

The Problem with Project Management

The Problem with Project Management

The Problem with Project Management

LinkedIn Recommendations Are Easy

The Catch-22 of Project Management Certification and Experience


Categories: Leadership


 

Leadership

 
This gets to be a hairy area of discussion, trying to define what makes good leadership.  I have no doubt there are many project managers who think they are fantastic leaders that I would classify as lousy, and many might say the same of me if we don't agree on the definitions.
 
I am heavily influenced by Drucker and Deming on this topic as well as some influential managers I've worked for in my career (thank you Tim and Jodi).
 

Strategic Planning

 
A project manager who isn't looking ahead isn't doing a good job leading. Not just schedules, but also making sure the right staff and materials are available when they are needed.
 
Risk management is part of this too. If you aren't leading the team to uncover and proactive handle potential issues on the horizon, who is?
 
No one. That's your job.
 

Continuous Improvement

 
Maintaining status quo is not leadership.
 
If you think your project organization has reached the limit of what is possible, please call me. I want to fly out to wherever you are and see it for myself.
 
If you aren't continuously getting better personally, as a team, as a project organization - you aren't leading.
 

Know the Work

 
Part of this is being at least moderately capable with the work your project staff are doing.
 
Some people claim a project manager can effectively lead a project in any domain regardless of their domain knowledge.
 
I say that's complete hogwash.
 
If you are managing a technical project and you have no technical understanding of what your staff do day to day, there's an automatic barrier to your ability to lead.
 
If you can participate in code reviews and facilitate technical discussion to give the team direction, you have a leadership-enabler at your disposal.
 
If you don't have a foundation of technical knowledge in the domain your project teams work, you'd better develop it quickly.
 

Trust, Not Fear

 
This failing is rampant.
 
Project managers don't want to hear bad news. They make a big fuss about problems or deadlines that are going to get missed, essentially blaming it on the team.
 
Here's what happens.
 
The team will stop telling you the truth, and instead just tell you what you want to hear.
 
They'll then go have their own conversations after you've given them direction - but they won't follow your direction because you no longer know what's really going on with the project. 
 
They'll go do their best to get things done without you - or more to the point, in spite of you.
 
That's a project culture of fear, and Deming would be disappointed.
 

Treat Project Staff as Volunteers

 
Relying on formal authority of your title is not leadership, it's the opposite of leadership.
 
When you treat project staff as if they were volunteers, you have to create an environment where they WANT to work with you on this project.
 
You empower them by employing techniques to enhance the pride they have in their work.  You give credit publicly for your staff's acheivements whenever it's sincerely warranted.
 
This is servant leadership, and without it you're just a manager. A warm body just punching the clock.
 

Systems Solutions

 
Mistakes are usually caused by flawed systems, not bad people.
 
This is why the project manager should take responsibility for mistakes and problems. Each one usually contains a lesson learned about how your project environment and systems should be improved to prevent this kind of mistake again (continuous improvement).
 

Customer Focus

 
The PMBOK used to say that a project was successful if the requirements were verified, regardless of whether or not the customer was happy with the product.
 
That's not leadership either.
 
A leader must have a focus on the customer, and frankly that's why I think it's so difficult to be an effective leader in (nearly) any project environment without doing iterative releases of your product and engaging your customer in a feedback loop on a regular basis.
 
This is why I believe Lean and Agile methods of delivering products are superior to any traditional method with long lag times between project phases.
 
What do you disagree with, and what you add? Leave a comment below and let's discuss.
 
The Problem With Project Management Series:
The less frequency with which your customer is directly involved in the project, the bigger barrier to true leadership you face.The Problem with Project Management
 
Leadership
 
This gets to be a hairy area of discussion, trying to define what makes good leadership.  I have no doubt there are many project managers who think they are fantastic leaders that I would classify as lousy, and many might say the same of me if we don't agree on the definitions.
 
I am heavily influenced by Drucker and Deming on this topic as well as some influential managers I've worked for in my career (thank you Tim and Jodi).
 
Strategic Planning
 
A project manager who isn't looking ahead isn't doing a good job leading. Not just schedules, but also making sure the right staff and materials are available when they are needed.
 
Risk management is part of this too. If you aren't leading the team to uncover and proactive handle potential issues on the horizon, who is?
 
No one. That's your job.
 
Continuous Improvement
 
Maintaining status quo is not leadership.
 
If you think your project organization has reached the limit of what is possible, please call me. I want to fly out to wherever you are and see it for myself.
 
If you aren't continuously getting better personally, as a team, as a project organization - you aren't leading.
 
Know the Work
 
Part of this is being at least moderately capable with the work your project staff are doing.
 
Some people claim a project manager can effectively lead a project in any domain regardless of their domain knowledge.
 
I say that's complete hogwash.
 
If you are managing a technical project and you have no technical understanding of what your staff do day to day, there's an automatic barrier to your ability to lead.
 
If you can participate in code reviews and facilitate technical discussion to give the team direction, you have a leadership-enabler at your disposal.
 
If you don't have a foundation of technical knowledge in the domain your project teams work, you'd better develop it quickly.
 
Trust, Not Fear
 
This failing is rampant.
 
Project managers don't want to hear bad news. They make a big fuss about problems or deadlines that are going to get missed, essentially blaming it on the team.
 
Here's what happens.
 
The team will stop telling you the truth, and instead just tell you what you want to hear.
 
They'll then go have their own conversations after you've given them direction - but they won't follow your direction because you no longer know what's really going on with the project. 
 
They'll go do their best to get things done without you - or more to the point, in spite of you.
 
That's a project culture of fear, and Deming would be disappointed.
 
Treat Staff as Volunteers
 
Relying on formal authority of your title is not leadership, it's the opposite of leadership.
 
When you treat project staff as if they were volunteers, you have to create an environment where they WANT to work with you on this project.
 
You empower them by employing techniques to enhance the pride they have in their work.  You give credit publicly for your staff's acheivements whenever it's sincerely warranted.
 
This is servant leadership, and without it you're just a manager. A warm body just punching the clock.
 
Systems Thinking
 
Mistakes are usually caused by flawed systems, not bad people.
 
This is why the project manager should take responsibility for mistakes and problems. Each one usually contains a lesson learned about how your project environment and systems should be improved to prevent this kind of mistake again (continuous improvement).
 
Customer Focus
 
The PMBOK used to say that a project was successful if the requirements were verified, regardless of whether or not the customer was happy with the product.
 
That's not leadership either.
 
A leader must have a focus on the customer, and frankly that's why I think it's so difficult to be an effective leader in (nearly) any project environment without doing iterative releases of your product and engaging your customer in a feedback loop on a regular basis.
 
This is why I believe Lean and Agile methods of delivering products are superior to any traditional method with long lag times between project phases.
 
The less frequency with which your customer is directly involved in the project, the bigger barrier to true leadership you face.z`The Problem with Project Management
 
Leadership
 
This gets to be a hairy area of discussion, trying to define what makes good leadership.  I have no doubt there are many project managers who think they are fantastic leaders that I would classify as lousy, and many might say the same of me if we don't agree on the definitions.
 
I am heavily influenced by Drucker and Deming on this topic as well as some influential managers I've worked for in my career (thank you Tim and Jodi).
 
Strategic Planning
 
A project manager who isn't looking ahead isn't doing a good job leading. Not just schedules, but also making sure the right staff and materials are available when they are needed.
 
Risk management is part of this too. If you aren't leading the team to uncover and proactive handle potential issues on the horizon, who is?
 
No one. That's your job.
 
Continuous Improvement
 
Maintaining status quo is not leadership.
 
If you think your project organization has reached the limit of what is possible, please call me. I want to fly out to wherever you are and see it for myself.
 
If you aren't continuously getting better personally, as a team, as a project organization - you aren't leading.
 
Know the Work
 
Part of this is being at least moderately capable with the work your project staff are doing.
 
Some people claim a project manager can effectively lead a project in any domain regardless of their domain knowledge.
 
I say that's complete hogwash.
 
If you are managing a technical project and you have no technical understanding of what your staff do day to day, there's an automatic barrier to your ability to lead.
 
If you can participate in code reviews and facilitate technical discussion to give the team direction, you have a leadership-enabler at your disposal.
 
If you don't have a foundation of technical knowledge in the domain your project teams work, you'd better develop it quickly.
 
Trust, Not Fear
 
This failing is rampant.
 
Project managers don't want to hear bad news. They make a big fuss about problems or deadlines that are going to get missed, essentially blaming it on the team.
 
Here's what happens.
 
The team will stop telling you the truth, and instead just tell you what you want to hear.
 
They'll then go have their own conversations after you've given them direction - but they won't follow your direction because you no longer know what's really going on with the project. 
 
They'll go do their best to get things done without you - or more to the point, in spite of you.
 
That's a project culture of fear, and Deming would be disappointed.
 
Treat Staff as Volunteers
 
Relying on formal authority of your title is not leadership, it's the opposite of leadership.
 
When you treat project staff as if they were volunteers, you have to create an environment where they WANT to work with you on this project.
 
You empower them by employing techniques to enhance the pride they have in their work.  You give credit publicly for your staff's acheivements whenever it's sincerely warranted.
 
This is servant leadership, and without it you're just a manager. A warm body just punching the clock.
 
Systems Thinking
 
Mistakes are usually caused by flawed systems, not bad people.
 
This is why the project manager should take responsibility for mistakes and problems. Each one usually contains a lesson learned about how your project environment and systems should be improved to prevent this kind of mistake again (continuous improvement).
 
Customer Focus
 
The PMBOK used to say that a project was successful if the requirements were verified, regardless of whether or not the customer was happy with the product.
 
That's not leadership either.
 
A leader must have a focus on the customer, and frankly that's why I think it's so difficult to be an effective leader in (nearly) any project environment without doing iterative releases of your product and engaging your customer in a feedback loop on a regular basis.
 
This is why I believe Lean and Agile methods of delivering products are superior to any traditional method with long lag times between project phases.
 
The less frequency with which your customer is directly involved in the project, the bigger barrier to true leadership you face.
Posted on: November 29, 2012 12:36 PM | Permalink

Comments (5)

Please login or join to subscribe to this item
Hi Don, great piece.

If I may add just one other item to the list - Dependence On Templates and so called Best Demonstrated Practices (as templates).

PMO's making it a requirement for PM's to tick all the boxes that they've used all the templates or BDP's for every project is just insane and to any point down right ridiculous and disregards the currency for simplicity which is the aggregation of agility, adaptability and most importantly the removal of bureaucracy.

I agree with all this, except the "KNOW THE WORK" section. While knowing the work can have value at times, it is just as often a barrier. Why? Because you cannot possibly know ALL the roles of the project team as well as they do, so anything you contribute is either going to be biased to those you do know, or you will provide a poor level of contribution that does nothing to help the issue or to build the respect the team may have for you.

Sure, if you happen to be an expert in a field apart from PM, and there is an issue, get stuck in, but getting involved in every technical aspect and offering your limited-understanding thoughts when those with expertise are seeking to come to a solution is just getting in the way.

You, as PM, are the facilitator. You engage those who have the skills, give them a mandate of what they need to produce which may be a business-level one or a specification provided by other experts, and you make sure they work together in a professional way. That is your role, and it needs no actual knowledge of the technical subject to deliver.

I think the art and science of Project Mangement is what keeps customers happy. The art of taking in verbal, non-verbal, and gut feelings and the science of using the tools, formulas and best-practices to get a whole project effort delivered.
Nice Job!

I agree with Bernard. PM is not a technical specialist. Project Management's role has an order of magnitude that is huge! A Project Manager leads the team towards project success. Technical skills can easily get dated quick. If an organization decides to have a Combo PM and Technical Lead, the organization will then have to make sure that this PM has all the necessary and updated certification at all times which may not be very possible and realistic. The business leadership and people management components of this project manager will suffer. There has to be an element of trust in managing projects. Pairing would be one way to address any conflicts of information that the project management may get from the team.

Just stumbled at this blog post randomly. I'm glad I did.

I definitely agree with the "Trust, Not Fear" piece. Many organizations are trying to look for ways to punish employees for mistakes which are much more noticeable than countless successes that the employee achieved prior to that mistake. Is using the stick (instead of the carrot) ever justified? If yes, in what situations?

Please Login/Register to leave a comment.

ADVERTISEMENTS

Even if you're on the right track, you'll get run over if you just sit there.

- Will Rogers

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events