pmStudent

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

The Problem with Project Management

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 (3)

The Problem with Project Management

Categories: Leadership, Lean

 

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)

The Problem with Project Management

Categories: Lean, Project Leadership

Value

Does your team know what value you bring to the process of creating products?
 
Do your stakeholders know?
 
Do you know?
 
One sad truth is the real value being added by project managers in some cases is very little.
 
Sometimes project managers get in the way of making progress in product development.
 
But even if a project manager is adding value, exactly how? And if people don't know about it, are you just fooling yourself?
 
If your team thinks you are just there to create slide decks, go to meetings, and be the book boss on the schedule - you're probably not as valuable as you think you are.
 
If your stakeholders and sponsor think you are just there so they have a single point of contact to interact with instead of having to talk to the team members - you're probably not as valuable as you think you are.
 

How To Really Add Value

 
It's going to be different on the various project sizes and types out there.
 
But in general you have to ask yourself one question.
 
"What would this project look like if I were not here?"
 
I have seen teams with a strong lead developer or just a strong internal leader within the team excel after a project manager leaves. They were holding the team back.
 
In my experience, these types of value-negative project managers come in two flavors.
 

The Bean Counter

 
The bean counter spends all day in spreadsheets and schedules.
 
The technical aspects of the product being developed are better left entirely to the team from his perspective.
 
As a result, the bean counter must rely heavily on technical staff even for briefings to stakeholders or sponsors. 
 
The bean counter spends many hours of the teams' time and their own getting very detailed and micro-managing on things like charge codes, ity-bity estimates, etc.
 
Very little value is being added - the technical staff would likely be making more progress without the bean counter.
 

The Guru Who Won't Let Go

 
The guru has come up through the ranks and is seen as one of the top technical resources around.
 
She probably got bored at being so awesome and wanted to branch out into project management.
 
But now she won't let go.
 
She may be very helpful and go out of her way to do everything she can. She carries the weight of the project on her shoulders. Everyone looks to her.
 
She's become a bottleneck for the project. All technical decisions go through her, even if she's not asking for it. The rest of the team just sees her as the person who should be making all decisions.
 
Chances are, if she were to leave the rest of the team is fully capable of stepping up and making those decisions. Their work would get done more quickly as they stop waiting on decisions for this over-worked guru.
 
She'd love to empower her team but doesn't know how. It just feels like she'd be letting them down if she told them to make their own decisions about the details.
 
Any of this sound familiar? Is project management a value-added activity in your organization?
 
How so?
 
The Problem With Project Management Series:
Any of this sound familiar? Is project management a value-added activity in your organization? How so?The Problem with Project Management: Value
 
Does your team know what value you bring to the process of creating products?
 
Do your stakeholders know?
 
Do you know?
 
One sad truth is the real value being added by project managers in some cases is very little.
 
Sometimes project managers get in the way of making progress in product development.
 
But even if a project manager is adding value, exactly how? And if people don't know about it, are you just fooling yourself?
 
If your team thinks you are just there to create slide decks, go to meetings, and be the book boss on the schedule - you're probably not as valuable as you think you are.
 
If your stakeholders and sponsor think you are just there so they have a single point of contact to interact with instead of having to talk to the team members - you're probably not as valuable as you think you are.
 
How To Really Add Value
 
It's going to be different on the various project sizes and types out there.
 
But in general you have to ask yourself one question.
 
"What would this project look like if I were not here?"
 
I have seen teams with a strong lead developer or just a strong internal leader within the team excel after a project manager leaves. They were holding the team back.
 
In my experience, these types of value-negative project managers come in two flavors.
 
The Bean Counter
 
The bean counter spends all day in spreadsheets and schedules.
 
The technical aspects of the product being developed are better left entirely to the team from his perspective.
 
As a result, the bean counter must rely heavily on technical staff even for briefings to stakeholders or sponsors. 
 
The bean counter spends many hours of the teams' time and their own getting very detailed and micro-managing on things like charge codes, ity-bity estimates, etc.
 
Very little value is being added - the technical staff would likely be making more progress without the bean counter.
 
The Guru Who Won't Let Go
 
The guru has come up through the ranks and is seen as one of the top technical resources around.
 
She probably got bored at being so awesome and wanted to branch out into project management.
 
But now she won't let go.
 
She may be very helpful and go out of her way to do everything she can. She carries the weight of the project on her shoulders. Everyone looks to her.
 
She's become a bottleneck for the project. All technical decisions go through her, even if she's not asking for it. The rest of the team just sees her as the person who should be making all decisions.
 
Chances are, if she were to leave the rest of the team is fully capable of stepping up and making those decisions. Their work would get done more quickly as they stop waiting on decisions for this over-worked guru.
 
She'd love to empower her team but doesn't know how. It just feels like she'd be letting them down if she told them to make their own decisions about the details.
 
Any of this sound familiar? Is project management a value-added activity in your organization? How so?
Posted on: November 20, 2012 06:47 PM | Permalink | Comments (0)

LinkedIn Recommendations Are Easy

Categories: Career

Someone asked me the other day (paraphrased):

"Josh, why do you have so many LinkedIn recommendations? Why don't I have any? What gives? I'm awesome too!"

You are awesome too.

I know you are.

So, here's how you do it.

Posted on: October 30, 2012 10:14 PM | Permalink | Comments (2)

The Catch-22 of Project Management Certification and Experience

Categories: Career, Certification

I get a lot of questions from people who are getting started in project management.

Many have a common theme around the problem of gaining experience when many of the positions that you find posted require a PMP certification.

Here's the deal.

What Catch-22?

It may seem like a Catch-22, but it's really not.

You know those jobs requiring PMP certification? Those are not entry level jobs you're applying for.

Any employer who is requiring PMP certification for an entry-level project management position does not understand what the PMP is. What you need instead is a more entry-level role if you don't have experience yet.

This can come in many forms. For many of us, we got our start by doing project management on the side. In addition to our day jobs we started managing projects. I realized that managing projects and creating something new was what I most enjoyed about managing people.

Another avenue is to secure a role such as Business Analyst or Technical Lead. More established companies will have different levels of project manager roles. One of the things that I teach is when assessing organizations you might want work for, take a look at what their organizational structure looks like. What sorts of titles do the different roles have in their company?

Corporate Project Culture

When you start to see a pattern of progressing levels of responsibility for project management rolls, this might be a good organization to grow your project management career with.

Examples include "Project Manager  1, 2, and 3" or progressive levels such as "Junior Project Manager", "Project Manager", "Senior Project Manager".

What about those of you who would rather work in smaller companies with maybe more of a startup feel to them? In many cases if you secure some type of lead technical role or people management role within my start up or small-company you will have the opportunity to manage projects. (You won't be able to avoid them!)

Startup Project Culture

In startup companies people wear many hats. That's how I got my start in project management. I did manage a few projects at a larger fortune 500 company, but I really got to manage a lot of projects when I was just the Operations Manager for a small startup company.

One of the downsides of doing this in a startup company is there is less of an established process or training in project management as a discipline.

But on the flipside you can learn SO much in a startup environment about business, product development, and leading teams that is hard to come by in a large and well-established company.  These people that thrive in a startup environment instead of the large corporate culture can show you a lot about getting things done.

I think that really helped me to start thinking critically about how projects are delivered, and one of the reasons why I'm a big advocate of Lean and Agile delivery methods today. If you spend your entire career within a large organization you don't really get exposed to this type of thinking much.

You really have to think about what type of environment excites and motivates you.

What Is Your Path?

Would you rather go into an established organization that probably has training manuals on project management and they have their software development lifecycle all mapped out on pretty little diagrams?

This can be a good environment for someone brand-new to project management to learn one way of managing projects.

Or do you get motivated by having to figure it out?

I am of the latter persuasion. I love to go into a situation that is fairly unstructured and inconsistent, and shape that culture into a highly performing delivery mechanism of products.

I did this even when I was starting out, and so can you.

Even when I really didn't have any experience yet managing projects in any kind of formal way, the challenge of trying to figure it out was an awesome incentive for learning as much as I could.

And you can do the same.

You Can't Wait To Be An "Expert"

You don't have to know everything there is to know about project management or even have any experience at it when you start out in either of these situations. For those of you like me who identify as lifelong learners and read several non-fiction books a month and attend training or webinars whenever you can, you can succeed in any of these environments.

If you're not naturally drawn to learn more every time every day about managing projects and delivering products, and you instead must force yourself to learn more about this process, then you may want to reconsider project management as a career path.

Seriously.

 If this doesn't excite you then why are you pursuing it as a career? You'll probably be doing this for the rest of your life - don't you want to enjoy it?

Posted on: October 16, 2012 07:41 PM | Permalink | Comments (4)
ADVERTISEMENTS

"If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time--a tremendous whack."

- Winston Churchill

ADVERTISEMENT

Sponsors