Eye on the Workforce

Workforce management is a key part of project success, but project managers often find it difficult to get trustworthy information on what really works. From interpersonal interactions to big workforce issues we'll look the latest research and proven techniques to find the most effective solutions for your projects.

About this Blog


Recent Posts

Planning Around Scarce Expertise (RPA & OCM)

Beware Haloes & Courtesy Copies

Communicating the Vision (RPA & OCM)

Communicate the Schedule Early (RPA & OCM)

Worth Hiding: Valuable Stakeholder Analysis

Beware Haloes & Courtesy Copies

As a project manager, managing people is a large component of your work. So it's worth Think about how you learn the techniques you use. Do some come from experience? From books, seminars or training courses? Did you learn some from watching others? Do you do things because everyone else does them?

Some of the techniques you use may be unproven. That is , they may not have been through rigorous testing to ensure they work. And if they have not, then you cannot be sure they work or even if they have the opposite effect than you want them to have.

Next, for your edification, are a couple of examples of what you can learn when people management techniques are studied.

Beware of the halo effect.

Imagine you are selecting between three candidates for a project analyst. You follow the common practice of interviewing the top candidates in order to choose the best one for the job in your project. The first comes recommended by people you have worked with and trust. They are in a different line of business with a very different culture, but tell you that the analyst has worked very well there. You talked to this candidate very briefly on the phone and liked her positive energy. She does not know much about your business, however.

The second candidate is from outside your company, but from the same line of business and a similar culture. He has plenty of experience. But, really…who cares?  You have a decent recommended candidate that can be quickly transferred into your project. She's one of those great performers who do well in any situation.

Hold it right there! You are under influence of the halo effect! This syndrome causes you to think that an individual who has been found to excel at one job, will be good at almost anything. This is not true. Many studies over the years have shown that the halo effect appears in many situations and that it can lead to problems for the worker and the business.

Typically candidate selection follows a standard process, but I have never seen one that is specifically designed to avoid the halo effect. You have to do that yourself.

  • When you are given candidates with high performance recommendations, check the circumstances under which that performance was achieved (job responsibilities, organizational complexity, culture).
  • If the circumstances  of your project are different, then give that recommendation less weight.

Beware the effects of the courtesy copy.

The second example is about the importance of knowing how to courtesy copy ("CC") people in emails. You probably have gotten the idea by now that communication and transparency can be improved easily by copying anyone involved on your emails. That way everyone is in the loop and cannot come back and say that they did not know what was going on. What did people ever do without email at work?

David De Cremer says his research indicates that courtesy copying can actually reduce trust, just the opposite effect that you want. Here's how you could be surprised in your project by the implications of your "courtesy":

  • You write an email to the QA lead with some planning questions. You copy the lead's boss because he is a very interested and participative business stakeholder to the project. But soon after you send the email, the QA lead comes to you asking why you copied his boss. Don't you think he was going to respond quickly enough? Has there been a problem in the past with his partnership?
  • When you write a request for participation in a series of meetings to a team lead in your project, you copy the team lead's boss in case the lead's boss had a problem with the amount of time, or other input. Right after you send the email, the lead calls you and asks if you have been asked by her boss to send updates on what you and her are doing.

These two examples show how workers can get the idea, whether true or not, that they are being monitored or micromanaged in some way. They get suspicious, especially in cultures where no clear policies in this area have been created. An undercurrent of mistrust leads to just the opposite culture than what was desired from this type of transparency.

What can you do in your project?

  • When developing your communication plan, discuss with team leads and stakeholders what information they want, and what is unnecessary. Generally, no leader or partner wants to sift through dozens of emails where project teams are working routinely, even if problem-solving. That's a productivity sink.
  • Create a project policy that sticks to this communication plan and lets teams work out problems on their own, without communicating "up". Specify that escalations will be used when teams cannot make progress without higher level participation, intervention or approval.
  • Watch for evidence of mistrust and intervene.

If you have experience with or other ideas on these topics, please comment.

The series on Organizational Change Management using Robotic Process Automation examples will return in my next post.

Posted on: August 22, 2017 08:39 AM | Permalink | Comments (17)

Communicating the Vision (RPA & OCM)

This is the second post in a series related to Robotic Process Automation*, begun in association with PMI's Information Systems and Technology Symposium, June 14, 2017, where I presented Becoming an RPA-Ready Project Manager. You can filter posts in this blog to find all related to "Robotic Process Automation".

Another component of organizational change management that you will need to monitor as a project manager is that the vision for the change has been communicated. Generally, you do not have to personally manage vision communication. It is the job of senior leaders to define and sometimes a special group helps to formalize the actual message into emails and intranet web pages. Still. it is wise for you to make sure it is going to be done properly or the tasks you are accountable for will not likely be successful as planned. You just have to love those out-of-project dependencies!

How do you know the vision of organizational change? It is a clear description of the target future state of the organization and the benefits that will be expected. Don't settle for anything less. For organization-wide RPA efforts, where the vision includes software robots doing some of the work previously done by most human resources, the description must include a more satisfactory workplace where workers complete less tedious, more valuable work.

If the vision is not communicated to everyone, your project gets run off the rails by

  • Conflicting interpretations of what the end point is leading to
  • Differing senses of impact by individuals or groups, differing senses of urgency
  • Ability of groups or individuals to promote their own agenda or pressure for certain changes
  • Changes occur, but not exactly what is needed to meet the vision. Interpretations change over time, or other factors.

Don't wait for these symptoms to occur, unless you are a masochist. Treat proper organizational communication as an Assumption, Dependency or something else formal and reportable. My paramour Amelia was wisecracking at lunch the other day that if you publicize a dependency for vision communication, then you might spur "someone" into action to do it!

What about the rollout of that vision? You will know effective, broad communication of the RPA effort vision is occurring when great practices for organization-wide communications are implemented. That includes:

  • Multiple channels used, such as email, dedicated intranet area, town hall sessions
  • Initial communications and ongoing updates
  • Executive participation
  • Q&A sessions with leaders

Make a note to look for these great practices to monitor your Assumption or Dependency. Don't see them? Consider managing as a Risk.

The communication should be continual and take many perspectives, such as

  • The importance of the organization's ability to succeed or avoid failure in marketplace, improve customer satisfaction. This addresses concerns of those who always ask the question "Why are we doing this in the first place? Everything was fine before."
  • The new structure to support better employee satisfaction
  • The new more productive and profitable business processes

Per member Philippe Schuler responding to the first OCM post, success stories are also important in organizational change management communications. In RPA projects, workers (users) will be expected to be skeptical of the changes, but evidence that it has worked well previously will help calm fears. Especially useful stories for RPA will include any that show the workers who have robots working for them are more productive and happy with their now more valuable work - and thus making the vision manifest.

If you start to see a lot of push-back to your RPA projects, it may not be your teams' fault, it could be inadequate organizational readiness for your projects. Consider escalating with that as a potential cause. The solution to that problem should be different than having you just push harder yet again. It could be resolved as a management problem beyond your role. 


* Robotic Process Automation:  For our purposes, configuring a software robot, using one of the relatively new tools available, to complete a certain part of a work process formerly completed by FTEs. RPA is not Artificial Intelligence, but simply a way of automating the execution of well-defined business rules. Projects are short and bring quick benefits to the organization.


Posted on: July 27, 2017 08:58 PM | Permalink | Comments (7)

Communicate the Schedule Early (RPA & OCM)

This is the first post in a series related to Robotic Process Automation*, begun in association with PMI's Information Systems and Technology Symposium, June 14, 2017, where I presented Becoming an RPA-Ready Project Manager. You will be able to filter posts in this blog to find all related to "Robotic Process Automation".

It's a couple of days after my presentation at the Symposium with an energetic crowd of attendees from all over the world. The chat stream was at times very funny. In addition to being a potential career path for us project managers, Robotic Process Automation lends itself to really humorous comments and interpretations. That will make it fun to talk about. Maybe we can all discuss it with my new girlfriend Amelia.

Let's get started.

As I said in my presentation, the first RPA-specific posts will be about Organizational Change Management (OCM). Organizational Change Management is a critical component of projects that require new work processes for people, on the business side or the technology side. RPA efforts are a perfect example. Unfortunately, the details of how this component integrates with project management is not always clear. It is worse when the organization in which you work does not have a mature OCM process to follow or a specific team that handles the OCM functions.

Picture it:  Your new work process project is chugging along. The technology is near to being deployed. Quality of the new technology looks very good. The budget did not go over too much, thank goodness. You are planning to transition the final resources out of the project. You will be able to take a few days off finally.

But wait! Alarms are going off! In emails at least. Not everyone is ready. One of the unready groups is the Help Desk team. They have not finished their training and other preparations. You also hear there is a similar situation with the users on the business side.

Fast forward to the lessons learned session. It's a bit awkward when the training issue comes up. The actual lesson earned cannot be immediately agreed to by the attendees. You have to wonder, "What happened?"

It could have been any number of factors, all within the OCM component. In this special series of posts, I will go over as many of these factors as I can, all in context of Robotic Process Automation (RPA) projects. These projects present good examples albeit with the increased need for urgency that RPA demands.
Adds to the drama.
And you love the drama.

Now back to OCM: One success factor for organizational change is that there is a general schedule communicated to all those affected by the change generated by your project. Not just the stakeholders. Not just the supervisors. The communication must be to all who are affected. They just need a summary of what will happen and when. They don't need your entire detailed work plan. This part of OCM has many benefits, including

  • Making the change appear more "real"
  • Building trust by showing that planning by multiple teams has gone into the effort
  • Providing everyone a consistent go live date
  • Building a sense of urgency around actions leading to the go live date
  • Showing specifically what leadership has agreed to
  • Helping the planning effort of other teams that may not be closely controlled or monitored by you

For RPA projects, specific target dates may be given for the following activities

  • Process re-design around use of the software robot
  • New definitions of roles (typically occurs if multiple roles can be consolidated once the software robot is in place)
  • User training (targeted to those who previously did the work previous to having the software robot as a support)
  • Support staff and supervisor training (help desk, supervisors of users, control partners)
  • Go live date

"Target dates" are fine, especially since it is best to communicate the high-level schedule as soon as possible. Later schedule revisions can be communicated in a timely fashion.

Communicating the general schedule of the steps leading to a work process and workforce change is just one part of managing that change. All together they will keep all teams associated with the project aligned, on time and with les resistance. Future posts in the series will cover other components of OCM and their relationship to RPA projects.


* Robotic Process Automation:  Configuring a software robot, using one of the relatively new tools available, to complete a certain part of a work process formerly completed by FTEs. RPA is not Artificial Intelligence, but simply a way of automating the execution of well-defined business rules. Projects are short and bring quick benefits to the organization.


Posted on: June 16, 2017 10:37 AM | Permalink | Comments (6)

Worth Hiding: Valuable Stakeholder Analysis

The best information on stakeholders is safest hidden away.

That's the gist of a point I made in an article recently.  The point was that good stakeholder information can be so controversial that you cannot place it in a standard stakeholder analysis document.

Stakeholders are a key part of your project workforce. And good stakeholder information is a very valuable project treasure. If you know your stakeholders well, you have already reduced surprises. 

The wise project manager keeps two kinds of stakeholder information. The first kind can be documented in standard forms and posted on sites for document sharing. The second kind should be kept away from public view.

So there is a public analysis and there is a private analysis. Your public analysis, includes information like

  • Preferred methods of communication/interaction
  • Requirements for project
  • Ability to participate
  • Preferred meeting cadence, time of day

Your private analysis can include all the public information, but have extra columns. These extra columns should show

  • Whether the stakeholder is a supporter of the project objective, an active resistor, a passive resistor, or a "bedfellow". A bedfellow is  passive supporter.
  • How it is to work with
  • Conflicts with other stakeholders
  • Level of power or prestige in the organization
  • Conditions of satisfaction (What it takes to be satisfied with project)
  • Needs for interaction / how close to keep
  • Level of interest / impact from project on activities

Consider creating a diagram with level of Power/prestige on the X axis and on the Y axis, a spectrum from  Fully opposes (project), Somewhat opposes, Neutral, Somewhat supports, Fully supports. Place stakeholders within this diagram.

How do you get this information? If you have been in an organization for a long time, you pick it up from experience. If you are new to an organization, then start talking to people informally about the stakeholders. Do your best from it appearing as an interview. You want the feel of a friendly (safe) conversation. Ask questions about the stakeholders.

  • "She says that she is a supporter, but is she really fully supportive of this effort?"
  • "How powerful is this person in the organization?"

And so on. You get the idea.

And, because this private information can be controversial if made public, you'll need to keep this for yourself in your own notebook or somewhere else where it will not get into other's hands. Like any valuable treasure.

Posted on: April 21, 2017 12:07 AM | Permalink | Comments (13)

Two Global Facilitation Techniques

This month we are looking at Global PM on ProjectManagement.com. Among the potential problems experienced when managing teams that are based on different continents is simply being successful at facilitating meetings.

You may not even see the problems during the meeting. Yet the meeting ends, everyone seems to agree and when it comes for tasks to be completed, or deliverables being delivered, there are problems. They seem to come out of nowhere, or everywhere. You follow your facilitation best practices, but they do not give you the same results as when you deal with teams that are co-located with you.

 There are many reasons for this (in fact, I have many articles and blog posts on this site dealing with cultural and other differences between experienced and well-meaning co-workers), so what you need are techniques you can use to help make sure there no surprises.


Wait 3 to 5 seconds after you ask a question or ask for comments.

Whenever you are in a meeting, listen for this situation: The leader or someone will ask "Are there any questions?" When this happens, count the number of seconds before the leader says something like, "OK, then, we can move on."

Typically, this will be about one second. That's way too fast, especially for a global meeting. How many times have you heard someone say, "Hey, sorry, but I want to go back to a previous topic"? They were victimized by the lack of response time.

Do not make that mistake. Wait three to five seconds. Count it out to make sure. It may seem like a lifetime, especially if you have had too much espresso, but wait.

Let us count the reasons why you should wait…

  1. Some personalities require more time to formulate questions in mind
  2. Language barrier
  3. Multi-tasking
  4. Fear of answering slowing response
  5. Embarrassment / shyness
  6. Lack of confidence
  7. Lack of comfort in role
  8. Getting approval to ask question from someone
  9. Getting help wording question properly
  10. Side conversation or chat interfering with attention
  11. Delay due to concern over whether question is polite
  12. Time delay in transmission lines

If you have additional reasons, please comment to this post. Maybe you have stories about bad communication in meetings with global participants.


Avoid blaming an individual directly or indirectly during a meeting.

A person may be the immediate noticeable target, but rarely the root cause that should be the target of an effective response. And when you blame an individual in a meeting where participants are from multiple geographic zones, it creates an environment of fear and confusion that is not sustainably productive to provide you with the results you need.

Among the many and varied reasons why blaming an individual is the wrong approach are

  1. The individual worker thought what was done was correct and had no information otherwise
  2. According to the culture of the team, there was no communication problem
  3. The worker followed the practice expected in the business location where the worker was based
  4. The worker valued politeness over another criterion which was very different than your preference, but was expected in the worker's geographical zone
  5. Project scheduling did not properly consider religious holidays required of the worker's geographic location.

A better approach for a globally-sensitive leader is to focus attention on where in the process or interactions things went wrong and work in a positive collaborative manner to resolve the problem and avoid it in the future. You should explain that the objective is for everyone to come out looking successful.

In related cultural conversations, you can explain that politeness should be interpreted as helping everyone on the project be successful even if it means having to be open and honest. Give yourself as an example.


This technique, while time-consuming is actually a powerful global team-building activity. It sets the stage for your workforce to resolve their own intra-team problems - without you!

Posted on: March 20, 2017 11:54 PM | Permalink | Comments (10)

"Humanity has advanced, when it has advanced, not because it has been sober, responsible and cautious, but because it has been playful, rebellious and immature."

- Tom Robbins