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

Communicate the Schedule Early (RPA & OCM)

Worth Hiding: Valuable Stakeholder Analysis

Two Global Facilitation Techniques

The Trick to Persuasion 2

The Trick to Persuasion

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

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

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

The Trick to Persuasion 2

We continue with the important topic of persuasion, giving you more and better ways to use the "persuasion tool.".

Here's a situation for you and a question:

You have to ask one of your team leads for an updated work schedule after a requirement was adjusted. Because of the decision meeting schedule, you need the update more quickly than will be comfortable for the team lead. You recall that the same team lead has rejected your requests the last couple of times. So should you expect better treatment this time or the same treatment as last time?

It's better to know in advance so that you can customize your approach. You don't want to take the wrong tone or say something that will make getting the information in a timely fashion less likely.


Use Previous Rejection to Your Advantage

Research was actually done related to this and the verdict is: Someone who has rejected you previously is more likely to grant your request. Perhaps it is because they are guilty from turning you down the first time. Doesn't really matter to you, actually. Make your request confidently, even if you have been rejected multiple times before, because the odds are in your favor.


Remind Target of Their Control

Unfortunately for us project managers, like the situation above, we are often in the situation where we can request that a task be done, but the individual we are requesting from does not have to grant our exact  request. Maybe they will grant the request eventually, but later than we need. Maybe they meet our timeline for providing information, but the quality of the information does not meet what we really need. We need all the persuasion tactics we can master to drive work to completion.

Ironically, you can be better off if you remind your target of their control when you frame your request. As part of your initial request, not later, you affirm the target's control in the situation by saying something like:

  • "You are certainly free to ignore this message. "  or
  • "I realize you do not have to do this..."  or
  • "Of course, you are not bound by the deadline mentioned."

There was a study done to confirm this was true looking across 42 separate previous studies. The tactic worked in most contexts, so definitely try it out when you make one of your more difficult requests.


Express Confidence in Worker Ability to Complete

If you are trying to persuade one or more people to complete a task, not necessarily make a decision, two points are important to get across:  your confidence that they can do it and that you are there to support the effort.


Assuming that you have defined what you want, a key motivator is that you have confidence that the worker or team can do the work. Say it clearly using words you are comfortable with. This statement reduces an unspoken concern over potential problems or failure that will result in negative consequences for those completing the task. This concern is always present, and more pronounced in certain environments, some of which you may have worked in. With this tactic, you can be the positive force that helps teams complete tasks in any environment.


For more on persuasion, check out where Christina DesMarais interviewed Clinical Psychologist Jeptha Tausig-Edwards.

What are tactics you use to persuade in difficult circumstances?

Posted on: February 04, 2017 07:10 AM | Permalink | Comments (3)

The Trick to Persuasion

When was the last time you had to be persuasive? Maybe it was to convince someone to start  something right away. Maye it was to overcome resistance to doing something at all. Whatever the case, it was a time when you had to use a "tool" project managers need: The ability to persuade.

I'll also wager that you used a tactic to persuade that you are comfortable with, maybe even out of habit, without considering whether it was the most effective method. You may have used a tactic that is common in your workplace. We mimic what we see in the workplace. We may even use a persuasion technique that would work on us.

The problem is that none of these reasons for choosing a method of persuasion are good. They do not guarantee that the most effective method is chose. If persuasion is an important project management tool, then care must be taken how it is used.

Researchers actually do studies to determine what techniques are effective. You should pay attention to what has been learned to make yourself a better project manager, able to get work done through others.   Today's post is the start of a series called "Friendly Persuasion" that will cover many aspects of persuasion relevant to project managers. It's actually a broad topic!

Recently in Inc.com, Christina DesMarais talked to Clinical Psychologist Jeptha Tausig-Edwards about what research has shown actually works when persuading others. There are particular points that apply to project managers.

Don't Bury the Headline In Your Request

This was in a topic in a previous post in this blog. When you are in a conversation where you are going to make your request, state request first. This generally increases your chance of being accepted.

This tactic can be applied to stakeholder interactions, where, for example, you need the individual's approval or you need to use the individual's resources for a period of time to keep your project on track.

  • Get your pitch ready in advance of the conversation. Start with an effective concise request that includes a benefit or avoidance of a problem.
  • Be ready with bullet points for the rationale.

This tactic works because studies found the reality is that those who you target with your request have other things on their mind or may simply be worn out. They appreciate you getting to the point.

Be Beneficial

In your pitch, be specific as to benefits of the made of your target. For example, you can say:

  • "I'm requesting that you approve a change request that will add one month to the schedule due to resources being temporarily assigned to other work. The advantage for you is that this will allow us to be able to keep system function you desired rather than putting it at risk."

Have a Back-up Plan

OK, so even if you have a good pitch, you may get rejected. Don't take "No" for an answer all the time, though. Be ready with a particular response tactic that may keep your options open so that you are not dead in the water.

Researchers have determined that the words you use in your reaction to "No" are critical to success. You have to use the alternative option format as shown in these examples:

  • If the sponsor cannot give you a decision by the deadline you have in mind, respond with "OK, can you get to it to me by Friday next week?"
  • If a stakeholder cannot release resources to your project as planned, respond with an option you have previously found to be the next best thing: "I understand the problem. So will you approve our project using contractors instead of your resources?"

The reason is to keep the individual from responding based on their preference and get them to respond based on their character. The work has to get done, you are asking your target decision-maker to help you with how the work is going to get done. 

As you can see, when you know what works, you can prepare for the interaction. You can even grab success from the jaws of failure. Perhaps more importantly, the tactic may be different in tone and content than a less effective method that you would have used without knowledge of research.

This topic is so important that I'll post additional proven tactics this month (and in the future) to start you off in the new year with better interaction skills.

Until then…Where have you had to apply your powers of persuasion? How did it go? Have you experienced bad attempts at persuading you?

Posted on: January 05, 2017 08:57 AM | Permalink | Comments (3)

"Whatever does not destroy me makes me stronger."

- Friedrich Wilhelm Nietzsche