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.

Change Management – The Process (Part 2)

“If you do not change direction, you may end up where you are heading.”
                                                                                                                                - Lao Tzu

This post concludes the series on change management that started with a discussion about what’s so confusing and is a continuation of my previous post on the process of project change management.  That post described the conceptual activities in project change management and why there are not explicit change management processes in the PMBoK.  Now it is appropriate to review what is in PMBoK and how it aligns with the conceptual activities.

The following PMBoK processes relate to project change management:
·         Develop project management plan
·         Plan [Knowledge Area] management
·         Direct and manage project work
·         Monitor & Control project work
·         Perform integrated change control

“Develop project management plan” and “Plan [Knowledge Area] management go hand-in-hand.  The project management plan includes each of the knowledge area management plans.  Each knowledge area plan (scope, time, cost, etc.) needs to include how change to that component will be managed.  In addition, the project management plan should describe how change requests are submitted, processed, reviewed and decided.

One thing I haven’t yet discussed is the two types of change.  There are, for example, changes to the product or service that is produced in “Direct and manage project work” and variance and compliance changes that are recognized in “Monitor and Control project work.”  We encountered both of these in a previous post on the philosophical dilemma of project change.  The project plans should,, of course, address how this dilemma is recognized and resolved in the “direct and manage” and “monitor and control” processes.

“Perform integrated change control” is the key to having project change work effectively.  It is here that change requests are received and processed.  As I mentioned in the previous post, this process is like initiating a complete mini-project for each request.  That’s why I have a dissonant response to Table 3-1 on page 60 of the PMBoK every time I pay attention to the location of 4.5 Perform Integrated Change Control, in the Monitoring and Controlling Process Group column.  Realistically, this step spans all five columns, from Initiating to Closing.  Not only does this span all process groups, but because a change to one functional group will trigger cascading changes in other functional groups, this activity also spans all functions (scope, time, cost, etc.), which is why it is integrated change control.

As I now bring this series to a close, the most important point to emphasize is that change will occur on your project, it will happen, and it must be planned for, you must prepare to have change, and you must have the processes and practices in place to effectively include, manage and control change in your project.

So now that you know everything I know about project change, what tips do you have for other PMs?

© 2013 Chuck Morton.  All Rights Reserved.

PM Journal – Risk in Complex Projects

Thamhain, Hans.  "Managing Risks in Complex Projects," Project ManagementJournal, April 2013 (Vol 44 #2), pp 20-35.

From discussions and networking with my peers and colleagues, I don’t think there are very many that read PM Journal.  I won’t suggest that’s a mistake because the applicability of the content varies – some articles are so academic and esoteric they are only of interest to the author’s mother, some are only applicable in narrow contexts, and some are a challenge to decipher.

In contrast, Hans Thamhain has written a very approachable and relevant article that I recommend to my readers (Yes, both of you).  He reports on the result of research on managing risk in complex projects (hence the title of his article).  Thamhain’s discussion of the current state of research and knowledge of risk in enterprise projects is both enlightening and disheartening:  “Predicting and controlling such [unknown] risks appears impossible with the existing organizational systems and management processes in place” (21) and “there is no framework currently available for handling risks that are either unknown or too dynamic to fit conventional management models” (22).  “…Many of the organizational tools and techniques that support early risk detection and management … readily exist in many organizations ….  Project managers, while actually using these project management tools and techniques extensively … do not give much credit to these operational systems for helping to deal with risks” (29).

The model he provides on pages 22-24 describing the three-dimensional relationship of risk characteristics (Uncertainty, Complexity and Impact) is easy to grasp and is probably valuable to introduce in your risk log for classifying risks.

Thamhain covers a variety of topics beneficial to PMs and, as the article’s title indicates, the focus is on the outsized consequences of risk effects that are not effectively managed.

I did find that since Thamhain shifts between discussing risks (a possible future event) and looking back after-the-fact to discuss the consequences, his terminology is sometimes confusing.  It’s like reading an article written by someone a few years in the future about something that for them happened a few months earlier.  They’re talking about something in their past that is still in my future.  I’ll offer a bit of guidance for readers of this article.  The word “contingency” appears throughout the article.  Late in the article he provides a couple of contextual definitions, undesirable events (29) and risk situations (30), which don’t help clarity.  However, from the article context it appears that he uses “risk” to refer to a future event and “contingency” to refer to a past event that was formerly a “risk.”  I would have used the term “risk event” to describe these, but I understand his difficulty.  The other confusion is the use of “issue.”  PM purists will no doubt object to Thamhain’s use of “risk issue,” but in context it translates to “the project issue that results from the occurrence of a risk event.”  I caution newbies to have a firm grasp on the distinctions between “risk” and “issue” before tackling this article.

One specific takeaway from the article that I want to share is worth noting by both PMs and managers.  PMs “blame project performance problems and failures predominantly on contingencies that originate outside their sphere of control … while senior management points directly at [PMs] for not managing effectively” (30).  Thamhain’s further commentary on this topic in the article should be read by both PMs and executives.  It probably deserves reworking for broader distribution, such as an article in PM Network.

For reference, my previous posts on project risk management:

·         The Project Manager’s Cycle – Review Risks & Mitigation Actions [Published:  03/06/2011]
·         The Schedule – Risk Buffers [Published:  12/28/2012]
·         Where to Find Risks  [Published:  03/20/2013]
·         Estimates, Schedules, Assumptions and Risks  [Published:  04/03/2013]

© 2013 Chuck Morton.  All Rights Reserved.

Change Management – The Process (Part 1)

“What you have become is the price you paid to get what you used to want.”

                                                               - Mignon McLaughlin, The Neurotic's Notebook, 1960

Continuing my series on Project Change Management, it is now time to drill into the change management process.  As I explained in my previous post in this series, the change management process is unlike other project management processes because it is not neatly contained, either by PMBoK knowledge area nor, except for one Monitoring and Controlling process, by PMBoK process group.  This post will attempt to demystify change management by examining what is in place, how it works, and what it could look like.

In the PMBoK (5^th ed), other than “Perform integrated change control” in the Monitoring and Controlling Process Group, the remaining change management activities are spread across and buried within the Knowledge Areas and Process Group activities.  So there’s a “perform” process, but how do you know what to “perform” if you don’t plan for it?  How can you “perform” an activity if you don’t recognize it?

Let’s start with an understanding of what, conceptually, project change is.  In a project, if you could alter the plan indiscriminately, there would be no need for a change management process.  The change process would be “do whatever you want, whenever you want” and, thus, the project would equally be “do whatever you want, whenever you want.”  Similarly, if there’s no plan, then there’s nothing to change.  So, project change is the formal approach for replacing an agreed-to plan with an amended agreed-to plan.  Since the plan establishes stakeholder expectations, change management is the structured approach for resetting expectations.

The word we usually use for “agreed-to plan” is baseline.

Let’s step through this from the beginning of a project:  The project is initiated, chartered and planned.  A project plan (time, cost, procurement, HR, scope, change, etc.) is produced, agreed to by the appropriate authorities (baselined) and published to stakeholders.  At this point, all stakeholders should be operating on the same expectations and you, the PM, should be reporting status, progress and variance based on the plan.  Now, someone comes along with a request to add a new feature (or get it done quicker, or cheaper, or without a key resource, or ….).  At that point, the project change management process is used.

The requestor submits the request according to the approved change management process.  The interesting thing here is that, regardless of how it’s described, the change activity is like a mini-project with all of the steps.  The change request is equivalent to a Charter.  The project team evaluates the request, estimating how the current project activities will be altered (new tasks, changed tasks, eliminated tasks, etc.) and creating a revised project plan, which must then be reviewed and approved (at which time it becomes the new baseline plan) or rejected (and the current plan remains effective).

So, if a stakeholder can submit a request to change the schedule, why isn’t there an “Evaluate schedule change request” or “Perform schedule change,” and likewise for all of the process groups?  As you – an experienced project manager – well know, all the project parts are connected:  you can’t tweak one area without somehow changing some other area.  Therefore, there is no time (or scope or cost or HR or procurement, etc.) change activity:  there is, reasonably, “Perform integrated change control.”

So I want to pause here:  I will continue this subject in my next post on this, where I will discuss how the current PMBoK activities relate to change management.

Does your organization have an effective and manageable project change management process?  How does it work?

© 2013 Chuck Morton.  All Rights Reserved.

PM Network – 6 Rookie Mistakes

"You only get one rookie season.  So, I hate that we lost, but this was one of the best games I’ve ever played in.”
                                                                                                - Chris Paul

I’ve been reading the April issues of PM Network and PM Journal, two key PMI publications available to all PMI members.  I’m going to interrupt my regularly scheduling programming to comment on a couple of articles that I found noteworthy.

The first, “6 Rookie Mistakes,” is by Ashley G. Richardson and is in the April issue of PM Network starting on page 44.  (I’ll cover the other article in a subsequent post.)  PM Network is not exactly the reference for scholarly or deep content, but Richardson identifies a half-dozen truly devastating mistakes that can derail any project.  While she labels her list as rookie mistakes, I don’t believe any of these are limited to rookies, but any PM who makes one of these mistakes should be truly embarrassed.

I’ll tease you with a couple of quotes, but urge you to read the whole article.  “Sometimes managing the team’s personalities can be more challenging than dealing with the tasks – especially if a member unwilling to pull his or her own weight is dragging everyone else down.” (46)  “If your organization lacks a set of standards around risk, seek out others who have done similar projects within the organization or find a more seasoned professional willing to provide guidance.” (48)

The nature of my blog is such that it has been much more focused on the “hard” or “technical” side of PM skills rather than the “soft” skills (something that will eventually transition).  There are a lot of PM bloggers out there who provide good advice on soft skills;  I saw an opportunity to add content where there wasn’t as much commentary.   But the soft skills are generally much more visible, harder to master and weakness is more severely penalized, so every PM needs to master both types of skills.

One thing I would like to know, though I wouldn’t expect to find this in a PM Network article, is how Ms. Richardson arrived at this specific list of six mistakes, especially if there is research backing the importance of these in particular.

I won’t ask you to embarrass yourself by posting a comment of your own rookie mistake, so I’ll instead ask what rookie mistakes you’ve observed and what happened?

© 2013 Chuck Morton.  All Rights Reserved.

Project Change Management – Process Overview

"Change is inevitable - except from a vending machine.”
                                                                                                - Robert C. Gallagher

Now that we have the confusions and dilemmas of change management behind us, it’s time to drill into the change management process. 

The one thing you can count on to stay the same when running a project is that there will be change.  Yet, the PMBoK (5^th ed, p60) identifies nine knowledge areas and change is not in the name of any.  And change is not in the name of the five process groups.  There is no process that says “Plan Change Management.”  If change is so prevalent, what is the process and where is it documented?

Some examples of change include:
·         We need to complete the project sooner.
·         We need to reduce the project budget.
·         We need to add this feature to the project scope.
·         This person has resigned, but we still need to complete the project.

In fact, there are eight broad areas where change can occur:  Scope, Time, Cost, Quality, HR, Communications, Risk, Procurement and Stakeholders.  This list, no coincidence, corresponds to eight of the PMI knowledge areas (PMBoK 5^th ed, p60).  But there is no “Deal with scope change” or “Handle HR disruption.”

As any practitioner of project management quickly learns, everything is connected to everything else and nothing happens in isolation.  It’s like there’s a seven dimensional pyramid (eight nodes), where there are 28 connections between the nodes.  (This concept also applies in communications management and communications planning related to the project team size.)  This means that if, for example, you need to complete the project sooner, that has a potential impact on all seven of the other knowledge areas that needs to be evaluated (and each impact to one of those has a potential impact on the other seven, etc.).  So, a “Deal with scope change” process cannot be done in isolation from time, cost, quality,….

Thus, we have, in the wisdom and experience of the PMI, the ninth knowledge area:  Project Integration Management with the process Perform Integrated Change Control.  This is the only practical technique for addressing project change – holistically across all areas.  But “perform” omits “plan” and “evaluate.”  It’s still not complete.

In the next installment of this series, I’ll drill deeper into the change process and how it works.

Has it occurred to you before that change management and communication management have this mathematical relationship?  What consequences can you foresee from this?

© 2013 Chuck Morton.  All Rights Reserved.

Project Change Management – A Philosophical Dilemma

"Our dilemma is that we hate change and love it at the same time; what we really want is for things to remain the same but get better.”
                                                                                                - Sydney J. Harris

Now that we know we’re discussing project change management, it’s time for a decision on how approved change will be addressed in the project.  Let me describe a scenario to help illustrate the two schools of thought.

You start a project and complete and baseline the plan.  It is a six month project.  Three months into the project, you are now one month behind when a key stakeholder requests a significant change to the project scope (a new feature).  You do the planning for this new feature and it will add two months to the project.  What is the new completion date?

One school says the new baseline is the former baseline plus the new change, meaning the project is now baselined as an eight-month project and still one month behind.  The other school says that the new baseline is current actual plus the new change, meaning the project is now baselined as a nine-month project and on schedule.  Advocates for the first method argue that the baseline shouldn’t absorb the delay just because they’ve proposed a change – and they’re right.  Advocates for the second method say that it doesn’t make sense to publish a new baseline with an inaccurate end date – and they’re right.  The ultimate choice depends on subjective considerations over which of the two better fits the organizational culture.

Since there is no absolute “right” or “wrong” choice between these schools, the participants should all understand how change management will work in this scenario (this would be a key section of the change management sections of the Time Management Plan and Cost Management Plan).  While this may not be a critical decision for a P&SD PM, for a consultancy PM or a contracted third-party organization providing PM services, this could be significant given that compensation (penalties and bonuses) may depend on whether the project is early, late or on schedule.

Like many controversies where there is no absolute “right” or “wrong,” this too will have practitioners who have an intuitive and firm position one way or another;  they may have difficulty understanding or even acknowledging the other view.  This can make discussions on the topic difficult because they can get emotional.

If you follow the first scenario, the project team has an incentive to “game” the change estimates, especially if there is a subjective component to the estimate.  That is, if they are behind or over budget, this is their opportunity to catch up, so it may not make much difference which school you prefer.

If you follow the second scenario, there may be stakeholders who feel the project team is taking advantage of them to erase variances.  Thus, in the end it comes down to the ethical practices of the project manager and the project team.

Which method do you use and why?  Have you experienced any problems caused by this?

© 2013 Chuck Morton.  All Rights Reserved.