Voices on Project Management

       By:  Rex M. Holmlin

This month’s theme at projectmanagement.com is “communication & collaboration.” I want to focus here on a crucial part of communication: confirming that we’ve understood the message someone has given us.

The PMBOK® Guide discusses what is called the “Basic Communications Model.” One aspect of this model, also known as the Shannon-Weaver Model, is the responsibility of the receiver to both decode a message and then confirm he or she has understood it.

Here’s a story to illustrate why that model matters.

A few years ago, I was in a project meeting about some stone we were going to purchase from a quarry in Egypt for flooring in an atrium. Stone is typically sourced by a stone broker. Stone brokers know the various quarries and work with everyone involved to select the correct stone from the quarry, get it turned into the proper size of tile and then get it to the project site.

As we wrapped up, I stood up and began to think about my next meeting. At this point, the stone broker came over to me. “You know,” he said, “stone is a natural material.” That’s not something anyone had ever mentioned to me before, but I acknowledged his statement. He seemed pleased, and I went to my next meeting.

A few weeks later, we received a call from Italy where the blocks of stone were being cut and turned into the flooring tiles. We learned that the tiles were crumbling into pieces when they went through the saws.

Fortunately, we had ordered the stone well before it needed to be installed, so there was time to source another block of stone, get it turned into tile and ship it to the project site. But later, as I reflected on this, I thought about the stone broker’s words. When he told me stone is a natural material, he was encoding a message that I’d failed to decode.

The message was that every piece of stone is different. This is one of the qualities that helps make stone beautiful and a key reason we want it in our homes and offices. Unlike steel or glass, stone might have veins of quartz or other imperfections that can cause the stone to crumble when cut.

Keep You Head in the Game

As I thought about it, I realized there were two things I did that contributed to an imperfect communications process. First, as I stood up, I “changed channels.” I was beginning to think about my next meeting. The lesson here is that if you’re in a meeting, be in that meeting. As a coach would say, “keep your head in the game.”

The second thing I did was fail to ask the stone broker to “Say more, please.” He likely would have told me a lot more about stone and the process of turning it into tile. The stone broker was not trying to conceal his meaning; he was being economical and selecting words that were meaningful to him.

This is something we all do. As the receiver of the message, I was the one responsible for confirming I had understood his message.

It may not always be the other party that causes a communication to fail. But it only takes a few seconds to ask someone to say more about the message they are trying to communicate. It also only takes a few seconds for us to confirm we’ve understood it. Sometimes taking the extra step to take these two actions can make a big difference in our projects.

By  Rex M. Holmlin

As project managers, we would like our projects to be successful. Successful projects are more fun and, as a general proposition, our bosses like it better when our projects are successful. But how can we set our projects up for success?

A helpful first step is to define what success is. For many of us, that means meeting scope, cost and schedule targets. However, I will argue that there are three levels of project success we should think about:

1. Project-level success

2. User-level project success

3. Enterprise-level project success

For a project to be truly successful, we must be successful on each level. 

Project-level success is the area most of us are most familiar with. Success at this level means we meet our scope, cost and schedule objectives. When we meet these objectives, many of us are looking for a ticker tape parade down the hallway. However, we are only looking at part of the success equation.

User-level success means delivering the benefits that the users desire from the project. While our users, and other stakeholders, may be interested in scope, cost and schedule objectives, the truth is we can meet project-level objectives and still have a project that does not deliver the benefits the users and stakeholders were looking for.

At the enterprise level, senior leaders in our organization are interested in having the projects that we execute make a positive contribution to key metrics at the enterprise level (profit targets are one example). We can meet project-level objectives, but not make a contribution to key enterprise-level metrics.

In a recent webinar, I asked the participants whether their organizations defined success at each of these levels. Approximately two-thirds of attendees felt their organizations had well-defined project-level objectives, but less than half of those felt their organizations set clear and well-defined user/stakeholder- and enterprise-level objectives

It is often quite challenging to meet scope, cost and schedule objectives. However, our projects will still fail if we do not deliver the benefits users and other stakeholders desire and make a contribution to key enterprise-level metrics. As project managers, we need to ask questions about the benefits users desire, and understand the key enterprise-level metrics we can contribute to. The more specific we are, the greater the chance we will have a successful project. When it comes to project success, ignorance about the other levels of project success is not bliss.

Please drop me a note and let me know if your organization defines all three levels of project success.

By: Rex M. Holmlin

Have you ever sat in your office and wondered whether anyone would notice if you disappeared? Whether anyone has noticed work you’ve done recently? At one point or another, practically all of us have felt that way.

One of our most important tasks as project managers is to recognize and reward team members. PMI’s PMBOK Guide acknowledges the importance of doing so by listing recognition and reward of team members as a tool and technique in the Develop Project Team Process section, which is part of the Project Human Resource Knowledge Area.

I teach project management to both undergraduate and graduate business students. When I bring up the topic of team member recognition to MBAs, who typically have several years of work experience, I always find it interesting to note how many of them feel they really can’t recognize people’s contributions.

Even experienced project managers often believe they don’t have the power to recognize or reward their team members. The hang-up seems to be that in many people’s minds, recognition and reward are synonymous with money. Since the authority to give raises typically rests with functional managers, this perspective makes sense.

But in my view it is very, very wrong.

In fact, project managers have a variety of significant tools at our disposal to recognize and reward our team members. The easiest, and perhaps the most powerful, is to thank them for something they have done. Going by someone’s office and thanking them for something specific is phenomenally impactful. Many team members are almost bowled over to discover that someone noticed what they’ve done.

All of us like to be part of something bigger than ourselves, like an exciting project. A certificate recognizing membership on a project team and contribution to the team effort can be very gratifying.

I have been involved with a number of natural disaster recovery efforts. One government agency I have worked with provides project members with 8.5-by-11-inch certificates noting their role in the disaster response and recovery effort. The certificates cost a few pennies, yet as you walk down the hallways you see them in small frames in nearly every office and cubicle.

With the advent of social media, the tools at our disposal for recognition have greatly increased. We can post a thank you to a Facebook page or endorse or recommend someone on LinkedIn. These are easy but meaningful ways to recognize someone.

You could also institute a “Player of the Month” award. Not everyone played sports when they were younger, and you may be surprised to learn how many of your project team members have never felt they were on a team. Being designated as the Player of the Month can sometimes be a life-changing event.

I believe very strongly that recognizing and rewarding team members is central to our role as project managers. If you agree, please share your favorite nonmonetary ways of rewarding team members—or ideas for doing so! I’ll collect them and make them available to our readers.

By Rex Holmlin

I teach project management to undergraduate and graduate students, and recently one of my students asked me which knowledge area was the most important.

My response: All the knowledge areas are important. Depending on the project and organizations involved, we would use more or less of the processes and tools, but most likely we would use all the knowledge areas in some way to help ensure project success.

But as I reflected on the question later, as well as my own nearly four decades of experience as a project manager, I realized my answer wasn’t great. In retrospect, I should have said Stakeholder Management is the most important knowledge area.

By training, I am an engineer. I love cost estimating and scheduling. But as important as these topics are, the source of most problems on projects is people. And the best way to avoid project problems is through the people involved in the project.

Therefore, paying attention to the four processes of stakeholder management can pay significantly more dividends to a project than a schedule or cost estimate.

When it comes to stakeholder management, I believe we shortchange our projects most often in two areas.The first is identification of stakeholders.

I am reminded of the movie Butch Cassidy and the Sundance Kid. Early in the film, train robbers Butch and Sundance are being chased by a posse. They stop to catch their breath, hoping they have lost the posse. When the lawmen appear over the ridge still on their trail, Butch and the Kid look at each other and say, “Who are those guys?”

This is the key question with the identification of stakeholders. We as project managers need to do a very thorough job of identifying the people, groups and organizations not only involved in the project, but who might be affected by it.

The second aspect of stakeholder management where project managers often fall short is stakeholder analysis. A Guide to the Project Management Body of Knowledge(PMBOK^® Guide)includes some great stakeholder analysis tools, but I recently came across an outstanding academic article(PDF link) by John Bryson of the University of Minnesota about stakeholder analysis.

It provides step-by-step instructions on 15 stakeholder analysis tools and techniques that can really take your understanding of the stakeholders in your project to the next level. I think you’ll find it both interesting and a potential source of tools to help you avoid a lot of the headaches we often encounter with project stakeholders. 

Which knowledge area do you think is the most important?