Do you know what I mean?
I've been guilty in the past of transitioning from a technical lead role into project management and continuing to make technical decisions that should have been the responsibility of the new lead who replaced me.
I had a schedule conflict with the 
Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
The Problem with Project Management
Categories:
Leadership
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)
The Problem with Project Management
|
Project management is often thought of as overhead.
Why is that?
Because in many cases, it's true.
Waste Have you ever tried doing a value stream map of the processes you are engaged with personally as a project manager?
No?
You should. It's enlightening.
A value stream map is simply the series of steps taken from the start to finish of the tangible or intangible products.
As a project manager, some of these products really are the end products of your project.
Some are support deliverables like schedules, reports, presentations, etc.
If you are like most project managers, you have a minimum of 5 'things' like this you directly take part in.
Value stream mapping is simply a way of making those processes explicit. With the maps in front of you, it becomes apparent pretty quickly where the waste is.
Sometimes the waste is time. When something sits on your desk waiting for action, that's waste.
Sometimes the waste is rework. Defects in a product of any kind that generate more work, or delivering the wrong thing.
There are many kinds of waste and sources of that waste. Here are a few examples you may find in relation to the role of project management on a project.
Bottlenecks
The best project managers can take vacations.
If your process for delivering projects requires your intervention and only you can do something, it's likely you haven't empowered your team enough.
It's also likely that even when you are present, someone is waiting on you.
A good example of this may be the bridge between the end users and your staff. Are you the only bridge there? Or do your end users and other stakeholders communicate effectively directly with your team?
Meetings
For the next week, look around the room at every meeting you attend. How many people are there and how much labor cost is going into that meeting? How much value is being generated by holding the meeting?
Is more value being generated than the cost involved? What's the ROI of the meeting?
As a general rule, the more people involved in a meeting, the lower ROI you can expect to find.
How many meetings could be cut out entirely? Is the same message being communicated multiple times - are you hearing it in multiple meetings?
How many meetings could be shorter while accomplishing same value?
In my anecdotal experience, you quickly run into diminishing returns after 30 minutes - and yet in our corporate culture it is common for the default meeting length to be 1 hour.
Work expands to fill the time alloted, and it's the same with meetings. Try making your default meeting length 30 minutes instead of an hour. Better yet, are there regular meetings that could be 15 minutes?
Process for Process' Sake
It's easy to add steps to a process over time.
It's very difficult to take steps away from a process.
People get used to the process, they sometimes get protective over their portion of a process.
The same goes for project managers.
Documentation gets created or versioned when no one will ever read it - because that's the process.
Project staff spend a half hour every day writing down details of exactly what they worked on that day when there is no effort to use any of that historical data for future project planning - because that's the process.
Change requests are generated for work that is really already part of the project plan - because that's the process.
Signature pages are routed around the building with 5-10 signatories even though this is just a minor update with little to no real content change and you'll be doing it again next month - because that's the process.
Well?
These are just a few examples.
The weird thing about waste is that it's all around us, but very hard to see unless you are looking for it.
Go try this yourself - for the work you do daily and the processes around you that you interact with.
The Problem With Project Management Series:
What will you discover?Project management is often thought of as overhead.
Why is that?
Because in many cases, it's true.
Waste
Have you ever tried doing a value stream map of the processes you are engaged with personally as a project manager?
No?
You should. It's enlightening.
A value stream map is simply the series of steps taken from the start to finish of the tangible or intangible products.
As a project manager, some of these products really are the end products of your project.
Some are support deliverables like schedules, reports, presentations, etc.
If you are like most project managers, you have a minimum of 5 'things' like this you directly take part in.
Value stream mapping is simply a way of making those processes explicit. With the maps in front of you, it becomes apparent pretty quickly where the waste is.
Sometimes the waste is time. When something sits on your desk waiting for action, that's waste.
Sometimes the waste is rework. Defects in a product of any kind that generate more work, or delivering the wrong thing.
There are many kinds of waste and sources of that waste. Here are a few examples you may find in relation to the role of project management on a project.
Bottlenecks
The best project managers can take vacations.
If your process for delivering projects requires your intervention and only you can do something, it's likely you haven't empowered your team enough.
It's also likely that even when you are present, someone is waiting on you.
A good example of this may be the bridge between the end users and your staff. Are you the only bridge there? Or do your end users and other stakeholders communicate effectively directly with your team?
Meetings
For the next week, look around the room at every meeting you attend. How many people are there and how much labor cost is going into that meeting? How much value is being generated by holding the meeting?
Is more value being generated than the cost involved? What's the ROI of the meeting?
As a general rule, the more people involved in a meeting, the lower ROI you can expect to find.
How many meetings could be cut out entirely? Is the same message being communicated multiple times - are you hearing it in multiple meetings?
How many meetings could be shorter while accomplishing same value?
In my anecdotal experience, you quickly run into diminishing returns after 30 minutes - and yet in our corporate culture it is common for the default meeting length to be 1 hour.
Work expands to fill the time alloted, and it's the same with meetings. Try making your default meeting length 30 minutes instead of an hour. Better yet, are there regular meetings that could be 15 minutes?
Process for Process' Sake
It's easy to add steps to a process over time.
It's very difficult to take steps away from a process.
People get used to the process, they sometimes get protective over their portion of a process.
The same goes for project managers.
Documentation gets created or versioned when no one will ever read it - because that's the process.
Project staff spend a half hour every day writing down details of exactly what they worked on that day when there is no effort to use any of that historical data for future project planning - because that's the process.
Change requests are generated for work that is really already part of the project plan - because that's the process.
Signature pages are routed around the building with 5-10 signatories even though this is just a minor update with little to no real content change and you'll be doing it again next month - because that's the process.
Well?
These are just a few examples.
The weird thing about waste is that it's all around us, but very hard to see unless you are looking for it.
Go try this yourself - for the work you do daily and the processes around you that you interact with.
What will you discover?
|
Posted on: November 21, 2012 05:10 PM
| Permalink |
Comments (3)
Sometimes, Project Management Sucks
Categories:
Leadership
Categories: Leadership
|
Like when you are developing a product using technologies that are relatively new and totally new to your team and stakeholders. While it is fun to be learning new things, it's damn hard to estimate effectively and stick to a schedule. Especially when the culture around you isn't used to new technologies or R&D-style projects. I mean, really. Like when programming languages that went out of style 20 years ago are still the core of most new development. Sometimes it seems like every day brings yet another unforeseen problem you weren't expecting at all. And you work with smart people. You're smart. Why is this happening? BreatheThe first step is to breathe. You may have to pivot, educate stakeholders, negotiate extensions. There are worse things in the world. You are the project manager after all, and you can get your team through this. Plus when you keep your head up and continue to be a role model for your team during tough times, something amazing can happen. Team GrowthThis situation can be turned to your advantage. There have been times I've been struggling like described above, and I was pleasantly surprised when my team took the pressure of our situation and used it as a tool to come together and execute. It can accelerate the storming phase of team formation when a strong leader on the team demonstrates optimism in the fact of adversity. When people see that 'can do' attitude, it becomes contagious. So, I say to myself and anyone else in this situation right now. Stop crying, little baby. Be a leader and show 'em what you're made of. |
Posted on: August 27, 2012 08:19 PM
| Permalink |
Comments (12)
Technical Project Managers - Get Out Of The Way
Categories:
Leadership
Categories: Leadership
|
I did this for about 6 months without even realizing it. People on the team were used to coming to me for advice and decisions on technical aspects of the projects, so they kept doing so even after the transition. We all want to be helpful, so I continued to answer their questions and provide technical leadership. I only directed people to the technical lead sporadically...if I was confident about my position on the matter, I just answered the question. Signs of TroubleThen I noticed my technical lead wasn't really doing all the things a technical lead should do...at first I thought perhaps they weren't 'stepping up' as much as they should to lead the team from a technical perspective. Then I realized it was ME who was crippling their ability to be a leader on the project. After that, when people would come to me for technical input, I would direct them to the lead to ask their advice. Rather than make decisions about implementation details, I would defer to them. Let me tell you, the difference is tremendous. A Technical Foundation Is ImportantI still firmly believe that every effective project manager must have a foundation of knowledge and experience in the domain they are managing. But when you empower your team (leads and all your team members) to take responsibility for most of the technical design and architecture, it makes everyone feel better about their job and frees you up to focus on strategic aspects of managing projects well. Right and Wrong ApproachesFurthermore, you and your technical lead may have a different opinion about the "right" way to implement something. Sometimes it's not a choice between "right" and "wrong" though, just two or more different possibilities that have their own pros and cons. If you as the project manager take the decision making power away from your lead and team members, you risk undermining them for no good reason. Even if you prefer option A, it's likely that option B is just as good. I'd rather let the team choose their own path as much as possible and only intervene when I have compelling reasons to believe one approach is far superior to the other. Get Strategic - It's Your JobSometimes as the project manager you can spot dependencies and additional risks that one approach will create that your team members don't see. Things like code maintenance and other product life cycle considerations may not be at the forefront of your team member's minds as they do their day-to-day work, but as the project manager that is part of your responsibility. Empowering Leadership From Your Team MembersEven in that case, whenever possible I like to educate the team about the risks I see and let them still make their own decision after getting all the facts. People who are actively involved with making decisions about the work they do have higher job satisfaction, are more productive, and a pleasure to work with. Share your experiences and thoughts in the comments. Technical Project Managers - Get Out Of The Way! <-- Click to Tweet This |
Posted on: June 22, 2012 11:30 AM
| Permalink |
Comments (12)
Difficult Decisions
Categories:
Leadership
Categories: Leadership
| Tweet
In projects and in life, difficult choices come up all the time.
The conflict was a local conference regarding education and advocacy for disabled children and adults. I'm very active in this area and was recently appointed to the South Dakota Council on Developmental Disabilities. Attending the RehabACTion & Transition Conference would be educational for me and help me do a better job in my role on the council. What To Do?As project managers, we are also faced with difficult decisions all the time. Here are some helpful techniques I use on a daily basis to make decisions. Engage Team Members and Encourage Dissenting ViewsOne of the most important things you can do is listen to the opinions of others who have a stake in the decision and know something about the options involved. Even if the final decision is yours, listening to diverse perspectives on the topic helps clarify your own thinking. The Vatican used to have a 'devils advocate' policy where someone was assigned to get as much 'dirt' on a candidate for the Papacy. This encouraged dissenting views. On my teams, I've found in some cases I need not actively pursue dissenting opinions. One of my teams just has the culture of personalities that everyone makes their own views known and are not afraid to pronounce them aggressively. This is awesome, but not all teams gel like this naturally where everyone is friends and pokes fun at each other, etc. On another team I do have to actively seek out dissenting views. My favorite technique for this is to read the tone and body language of team members when discussing a decision that needs to be made. I select a few who I think may not like my preference by asking them directly but with a gentle smile, "[name], I would like you to tell me why this is not the right decision. I want to know why this is a bad idea, because it might be." It can take new teams awhile to adjust to this, because almost no project manager actively seeks out dissenting views. They will likely be hesitant at first, and may even feel like you are picking on them. With a new team, I will sometimes tell everyone ahead of time that I want them to come up with at least 1 reason why each option is a bad idea. I do the same. Then we share our negative opinions of each option. This makes the team comfortable with voicing their opinions by demonstrating that I value their input, regardless of whether they agree with me or not. The most dangerous thing a project manager can have is a team of 'yes' people. Write It DownI also love the process of writing down pros and cons of each option in a decision. The act of writing it down helps me ensure I've thought thoroughly about each option. In many cases I discover questions I hadn't thought of previously when I go to write the context, pros and cons of each option down. Specifically, I like to think in terms of value. What value is added or taken away with each option? If you don't use something like value-added as a criteria, you can still end up deciding on what 'feels' better, which is a bad idea. Human intuition can be great, but it goes wrong with complex decisions more often than it goes right. In The EndI decided that I'll add more value to the world by attending the disabilities conference than I would by presenting and attending the PMI Global Congress. It was a difficult decision still, but I'm confident I made the right one. My team members in this case were my wife and some close family members. When I wrote the options down, it became clear the primary benefits for attending the PMI conference were networking with people there and the prestige of speaking again at a large project management conference. However, the majority of the people I interact with at the PMI Congress are not engaged with my target audience for pmStudent, which is new and aspiring project managers. The majority of the companies and people in this space focus on things like delivering PDUs, consulting for companies, etc. When it was written down, it became evident that I can add more value at the disabilities conference - especially in terms of value to others. So while I'm sorry to miss this year's PMI event, I'm also confident I've made the right decision. Will you leave a comment and tell me how you make difficult decisions? Tweet |
Posted on: September 17, 2011 11:27 AM
| Permalink |
Comments (4)