Power Listening

Power Listening: Mastering the Most Critical Business Skill of All.  Bernard T. Ferrari. Portfolio/Penguin, 2012.

I highly recommend Power Listening by Bernard T. Ferrari for PMs (and managers, executives, BAs, spouses, parents, children, …).  This book doesn’t offer platitudes about why listening is important;  in fact, Ferrari, who is obviously experienced with coaching on this subject, offers specific direction on, not just the why but, the how of listening.

The first few chapters of Power Listening are devoted to documenting archetypes of listening failures:  Opinionator, Grouch, Preambler, Perseverator, Answer Man, and Pretender.  These are described sufficiently well so that you can recognize them when you encounter them in others but, more importantly, when you find yourself, as we all do at various times, exhibiting these characteristics.  These opening chapters help us recognize poor listening archetypes, understand why each of these deficiencies prevents us from reaching our potential as listeners, and provide techniques for breaking bad habits associated with poor listening.

The meat of the book follows, though.  Here Ferrari provides the structure to swing from poor listening to Power Listening, by providing a schema for collecting and organizing (mandate, plan, team, execution and personal) information.  The goal of power listening (the technique) is to make better business decisions and this section helps us to better know when we are (still) missing critical information and what questions to ask to fill the gaps.  Knowing what questions to ask is beneficial;  knowing what information is missing is priceless.

The final section of Ferrari’s book explains how the organizational leader’s listening skills set the tone for the organization and that the leader can improve the organization by modeling Power Listening skills.

Communications is the most important skill in project management.  Therefore, anything we can do to improve communication skills – for ourselves, our project teams and our stakeholders – should be explored and practiced.  This book should be in your library;  these skills should be in your toolset.

© 2013 Chuck Morton.  All Rights Reserved.

How Should Project Manager’s Be Measured?

"Being in power is like being a lady. If you have to tell people you are, you aren't”

                                                                                                - Margaret Thatcher

“How should I measure my PMs?” is a frequent question (in a number of variants) on various LinkedIn discussion boards.  The classical answer to this question, of course, is that the Project Manager is measured on their success at delivering the contracted/ chartered scope on time and within budget.  The practical answer is not so simple.

The traditional response is based on the purist PMI definition of a project and project manager:  a Sponsor funds a specific project (agreed-on scope, time and cost) and the PM has complete authority and autonomy to deliver the project.  In this scenario, it is proper to base the PM’s performance on those criteria.

I don’t know about you, but I’ve never worked on a project like that.  So let’s look at a couple of scenarios more consistent with what I’ve experienced.  In the first, the PM is assigned to a VP or senior manager and is their agent for delivering their project.  (From the purist PMI definition, the executive is the PM, but that’s not how it’s recognized in the industry.)  In this scenario, the PM is the agent of the executive;  the executive makes the strategic and significant controlling decisions;  the PM is responsible for tactical and operational delivery on behalf of the executive and for monitoring and reporting.  The key PM skill is proactive stakeholder communications.

This PM should not be measured on the traditional criteria:  they don’t have the authority to make significant or strategic resource reallocations to meet the project objectives.  However, this PM should be measured on the quality of the plan (relative to the organization’s delivery capability), the quality of the schedule, delivery to plan and frequency, appropriateness and quality of communications.  On this last point, communications, for example, the PM should be measured on how well they keep the stakeholders (particularly the executive) informed about variances from plan, but the PM should not be assessed on the magnitude of the variations, that there are variations or the response to the variations.

Another common scenario is that the PM is assigned to a PMO or that the organization has a formal, well-defined project delivery process.  In this scenario, the organization, not the PM, takes on the responsibility for delivering scope within time and cost by specifying the process.  In this scenario, the PM should be measured on adhering to the process, the quality of the deliverables and the contribution to improving the process.

There is an important lesson in this scenario:  if the PM follows the process and the project fails, the PM was successful;  if the PM doesn’t follow the process, regardless of whether the project is a success, the PM has failed.  This may sound heretical, but is the difference between how GM and Toyota manufacture cars.  For GM, delivering a car on schedule is paramount, regardless of the process disruption.  Thus, each car becomes a one-off craftsman product with inconsistent quality (results are not in statistical control and quality is tested in).  In contrast, for Toyota the process is paramount.  If the process is not working properly, they will stop the process until the problem is corrected.  That is a true assembly line and the product quality is consistent.

If your organization has a project delivery methodology, the only way to know if it works is to apply it absolutely and allow it to succeed or fail.  If it fails, then do the appropriate root cause analysis and problem resolution to improve the process.  Thus, a PM who shortchanges the process is not benefiting the long-term quality of the organization.

The bottom line is that the PM should be evaluated based on their performance within their span of control and to the organization’s delivery objectives.  Use of any other criteria creates dissonance between what you say you want and want you are rewarding the PM for.  To paraphrase Sgt. Esterhaus, “Let’s be consistent out there.”

What experience do you have with inconsistencies between the reality of what the PM does and how the PM is measured?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Manager’s Cycle – Redux

“What does a project manager do?  What value do I add to your project?  It’s true that I don’t contribute directly to the product or service for which the project exists.  However, if I’m doing my job well, then I add significantly to the productivity and value of the team by improving communications, eliciting priorities, and focusing the team on the key deliverables.  Further, I am your agent, seeing that we perform to plan and communicating back when we diverge from it.”

Note:  I originally wrote this in April/May 2011 and it was intended to be the final post in The Project Manager's Cycle series, but on reviewing my archives today I realized that I never published it.  My apologies... and here it (finally) is.

The Project Manager’s Cycle includes these activities:

• Validate the metrics
• Validate task status
• Incorporate approved change control
• Reschedule/Replan
• Check variances and progress/productivity
• Communicate planned/expected resource utilization to resource managers
• Develop earned value reports
• Review risks and mitigation actions
• Review issues and action items
• Review commitments
• Conduct client/sponsor status meeting
• Conduct project team meeting
• Publish the project status report

A baker’s dozen posts on the core project management elements of monitoring and controlling a project.  This series on The Project Manager’s Cycle been a pleasure to write and has also been beneficial for me.  I developed the outline of the series several years ago, but this journey required that I really flesh out the details, relationships, and components.  I appreciate all of my reader (yes, that would be you) who stayed with me through this.

A picture is worth a few words, it’s said, so I’ve tried to rough out the series in a diagram.  If I ever figure out how to make it available as a download, I’ll enable that.  In the meantime, leave a post or drop me an email and I’ll reply with a full-size PDF of version 1.0 of the diagram.  Next time I’m feeling ambitious, I’ll add the inputs and outputs, though I’m concerned that will make the diagram too busy.

We stepped on the ferris wheel together in January to start this ride.  We’ve gone around the cycle and now it’s time for us to step off.

What of this series has been the most beneficial to you?  Where have I not been clear and need to expand or improve the discussion?

The Project Manager’s Cycle – Redux

“What does a project manager do?  What value do I add to your project?  It’s true that I don’t contribute directly to the product or service for which the project exists.  However, if I’m doing my job well, then I add significantly to the productivity and value of the team by improving communications, eliciting priorities, and focusing the team on the key deliverables.  Further, I am your agent, seeing that we perform to plan and communicating back when we diverge from it.”

The Project Manager’s Cycle includes these activities:

·         Validate the metrics

·         Validate task status

·         Incorporate approved change control

·         Reschedule/Replan

·         Check variances and progress/productivity

·         Communicate planned/expected resource utilization to resource managers

·         Develop earned value reports

·         Review risks and mitigation actions

·         Review issues and action items

·         Review commitments

·         Conduct client/sponsor status meeting

·         Conduct project team meeting

·         Publish the project status report

A baker’s dozen posts on the core project management elements of monitoring and controlling a project.  This series on The Project Manager’s Cycle been a pleasure to write and has also been beneficial for me.  I developed the outline of the series several years ago, but this journey required that I really flesh out the details, relationships, and components.  I appreciate all of my reader (yes, that would be you) who stayed with me through this.

A picture is worth a few words, it’s said, so I’ve tried to rough out the series in a diagram.  If I ever figure out how to make it available as a download, I’ll enable that.  In the meantime, leave a post or drop me an email and I’ll reply with a full-size PDF of version 1.0 of the diagram.  Next time I’m feeling ambitious, I’ll add the inputs and outputs, though I’m concerned that will make the diagram too busy.

We stepped on the ferris wheel together in January to start this ride.  We’ve gone around the cycle and now it’s time for us to step off.

What of this series has been the most beneficial to you?  Where have I not been clear and need to expand or improve the discussion?

Communications, Communications, Communications

It seems appropriate to initiate a blog about project management best practices with a discourse on communications.  I certainly have plenty to communicate.  I look forward to sharing my thoughts with you.  May you find some of them interesting to read.

The description of this blog documents my intent and will drive the selection and direction of content.  I will present here my thoughts on PM best practices;  I invite your feedback, critiques, support, and disagreement so that we share a discussion;  and I hope that from my humble contributions someone finds a gem and takes a step to improve their organization.

So what does “communications” have to do with best practices?  Communications isn’t a best practice.  Communications is just sort of what happens when we project managers do what we’re supposed to do.  Publish a project schedule?  That’s communications and fosters communications – team members and stakeholders either accept it or they object, and the ensuing discussion improves the schedule and everyone’s understanding.

Project plan (and, notice that project plan is different than the schedule).  Negotiating the plan (and the component plans for managing costs, resources, risks, vendors, etc.) causes team members and stakeholders to understand how each role contributes to the ultimate result.

A well-prepared project status report is a key communications tool, providing a snap-shot of the project state (relative to plan), accomplishments, issues, etc.  The status report is like a diary, providing a continuing narrative of the project state.

The risk register, issue log, change requests, EVM graph, deliverable acceptance form, and everything we as PMs produce are just there to force two or more people to see the same content presented in concrete form and either accept it or talk.  By publishing the content, you prevent misunderstandings and misaligned assumptions.  I’ve been amazed over the years how many project problems have been avoided just by forcing two people to talk to each other.

Each of these documents are best practices for a reason – projects work better with them.  They’ve been proven by experience.  That is, when they are used projects are likely to be more successful than when they are not used.

So I’m going to communicate.  I’m going to share what I’ve learned.  Maybe somewhere in my ramblings you’ll find a gem that helps you on one of your projects.  Until then…

Communicate, communicate, communicate.