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

Help Yourself by Helping Your Team

Countering the Most Difficult Strategy Implementation Obstacles

Resource Problems in Org Change Management (RPA)

Better to Be Competent or Warm?

The Blessing and Curse of the Long-Duration Task

Countering the Most Difficult Strategy Implementation Obstacles

In my article this month I discussed tactics to assist you with strategy implementation by maintaining the proper culture. That article did not look at troubleshooting tactics, but I'm rectifying that here with several troubleshooting tactics that will help you take your career to the next level. You might want to check out the article first to make sure you get certain background information.

On to troubleshooting. Recall that in a project or program closely associated with strategy implementation, you as a project manager have a critical role in helping achieve the business strategy. That gives you a certain prestige, power, cache. Don't be afraid to use it. But use it wisely by taking careful steps.

Characterize identified obstacles to escalate properly

Suppose you identify an obstacle to implementing business strategy such low participation by one or more stakeholders. Is the cause simple overallocation or actually resistance to the strategy? Those are two very different situations. If you can, you need to know before you can effectively intervene.

Problems that stakeholders report that are from known competing priorities or reduced resources are common and can be handled through your typical risk and issue management. On the other hand, problems arising from certain "silos" that do not want to participate, require a different tactic.

What would be the cause of resistance to the business strategy? Some individuals, job roles, or departments can be affected negatively by the strategic plan being implemented. Jobs can be lowered in prestige, shifted around the organizational structure or even lost. Implementing business strategy is serious business. And you can represent danger as the project manager. Even if the fear or anxiety is unfounded resistance can still affect your "strategy" project and must be dealt with.

What might you hear from a stakeholder or partner if there is resistance to the business strategy? Hint: You will not hear "I disagree with the business strategy." But listen for phrasing like in these examples:

  • "I have the resources to assign, I just don't see how this department benefits."
  • "This division's focus is really in a different direction."
  • "Your project is not part of what our group supports."
  • "Look, I just can't support this project."

Or you may get a tip off from another stakeholder or sponsor that one or more stakeholders are known to be negatively affected by the strategic changes and then see actual resistance.

Intervene effectively for resistance to the strategy

Suppose that you have followed all these steps and identified and have evidence that a stakeholder Is not participating because of resistance to the strategy itself. In this case you must use a very specific type of intervention that is unlike the regular risk and issue management process you normally follow.

  • Get guidance from the sponsor for the first step. Depending on the specific stakeholder (or group) and situation, you may be asked to intervene with a certain message. Alternately, it may be taken up by higher levels of the organization associated with strategy.
  • If you have the intervention conversation, prepare so you are confident and clear. Remember that you have the prestige of managing a project directly connected with implementing business strategy. The effort requires participation.
  • If you escalate, be prepared for the "organizational" resolution to take some time. Ask the sponsor if it is appropriate to "pause" your project if you cannot push work any further.

Projects implementing business strategy are not given to just any project manager. You have to be able to handle the basics without thinking too much because you are dealing with higher-level risks and stakeholders - and the stakes are greater. Succeed by using your understanding of business relationships and breaking down complex problems into step-by-step solutions.


Posted on: August 07, 2019 09:50 PM | Permalink | Comments (8)

Resource Problems in Org Change Management (RPA)

This is the fourth 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 "RPA". You can also watch that presentation for PDU credit.

Without the right prepared resources during organizational change, frustration will be the order of the day. Deadlines will cause conflict. The much-touted vision will ring hollow. Success will be difficult.

In an initiative where organizational change is brought about by automation, including rolling RPA projects, resources have to be available at certain times to complete specific work. If they are not available, then the frustration spiral takes over. Examples below from such a hypothetical organizational change show how to identify and deal with resource problems and how to avoid errors managing resources over which you have control.


Organizational Change Effort Role: RPA Project Team Business Process Specialists

Potential Problem: You lead an RPA project that will be completed within a couple of months and representatives from the business that know the process to be automated are not available or not assigned near the point at which you are to start. This could be due to:

  • Group’s lack of knowledge of the commitment required in such a project. The work is rapid and agile-like if not agile, and the significant time involved for many days is not familiar to some.
  • Group does not have firm acceptance of the vision of the organizational change.

…or other reasons


What You Can Do as Project Manager:  No matter what the reason that caused the problem,

  • Ask advice on how to proceed from your peers in the organizational change effort. Nuance is critical for your success.
  • Attempt to contact the individual in charge of assignments to understand what the situation is and resolve it quickly.
  • Log a risk or issue if you don't have name(s) on time.
  • Talk directly to assigned specialists and explain what specific time commitments are required. Identify any lack of availability during project.
  • Communicate to stakeholders any availability problems. Again, log a risk or issue to manage this formally. In a short project, any small delay hurts.

Organizational Change Effort Role: Change Specialists

Potential Problem:  Your project is dependent on a separate effort to communicate about the change in advance and to get general agreement with the vision but evidence you see does not indicate that the communication has occurred, or the vision has been accepted. This could be caused by:

  • Too few change specialists
  • Badly managed change communications
  • Change specialist (or change manager) role given to some who did not have time or ability to do it correctly

…among other reasons.

The result is that certain project team members, partners, stakeholders are not hurrying to work with you. They do not know what your project is. Or they are avoiding your project.

What You Can Do as Project Manager:  No matter what the reason that caused the bad communications, you must act when the environment is not conducive to success. In any organizational change effort,

  • Attempt to contact change specialists who can remediate the problems with communication/training. Be positive, but don't hold your breath waiting.
  • Raise a risk if there is a pattern of non-participation or obstacles related to lack of communication. Be specific about who has not committed as expected by a certain date and what the consequences are to the project. Do not exaggerate. Clarity on your part minimizes ugly drama that can be involved in resolution.
  • Look for change-related communications sent (or that should have been sent) by change specialists, explaining what the organization is doing for automation and the benefits being sought. They may also include success stories from elsewhere in the organization. Integrate key principles and points in your communications for your specific project for continuity of message.


There are many other roles in an RPA project, but the example of business process specialists is good to address because success of the project is mostly dependent on their availability.  Likewise, there are many roles in a large organizational change effort, even one that is solely built around continuous automations. Change specialists are key to setting up a positive environment for you to manage your project. Unfortunately, you as a project manager have less authority to manage problems associated with roles outside the scope of your project. Still, your usual tactics of (a) direct communications with constructive problem-solving and (b) risk management are useful there as well. Using those tactics will make you a positive force against frustration in organizational change.

(If you are thinking that Resources needs certain skills for automation projects and organizational change then you are correct, but we will deal with the issue of skills in a future post.)


* 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 21, 2019 01:13 AM | Permalink | Comments (2)

Better to Be Competent or Warm?

If you were to go back through postings on this blog over the many years that it has been in existence, you would find that many of the tips and tactics covered fall under the category of “ways to improve the work environment so that workers can do their best”.  To be able to manage an environment is a high-leverage technique for a project manager. You would do well to identify and build as many skills in this area as you can.

Here’s one now!

A recent study helps you understand in a more sophisticated way how to interact so that you create a more productive environment for your project team.

Before getting into the details of the study and pulling out useful tactics for a project manager, it’s useful to ask yourself: Is it better for me to appear as competent or to appear as warm? You might think it is best to be both. You might think it is more important for you to appear competent because your team does not have to like you, they just have to respect your authority and ability.

There are certainly different ways to look at this and, of course, different project managers have different personalities. But if your objective is to create a productive workplace, it is important to strike the right balance in a given situation, to understand what behaviors create the environment where workers will thrive. This study helps you do that - with a little help from my tactics provided after the description of the study.

The study was supported by Carnegie Mellon University and led by Shereen J. Chaudhry, who was trying to determine how and why people use apologizing, thanking, bragging and blaming. The study used clever scenarios with winners and losers and researchers monitored what happened on live chats after the winner was revealed. Sometimes the environment and outcome was fixed to really test researcher's predictions. (Hard to tell whether that would have been fun or just a little creepy.) Researchers interviewed participants afterwards to gather more information.

The outcome of the study confirmed predictions and made additional discoveries, including:

  • People generally prefer thanking far more than bragging.
    (Notice that there is a preference to be polite or appear "warm" in a social setting.)
  • People even preferred to thank or apologize albeit reluctantly when it was important in the environment to appear competent.
    (Notice how there is a fear that thanking and apologizing are seen to make someone look less competent, but it is preferred to appear warm.)
  • "Winners" tend to want to experience gratitude, so may "prompt" others when it is not forthcoming.
  • When given an opportunity to work again with a participant, preference went to those who chatted previously and who used techniques to appear warm over other participants who did not either participate in a live chat or those who appeared less warm in previous interactions.
  • Thanking and apologizing occur less often after bragging and blaming occur.

You can employ certain tactics based on this information, such as

  • Show gratitude to your project team for their work. Provide an authentic apology when appropriate.
  • Prompt your team to show gratitude until it becomes a habit. (Have you seen meetings where gratitude is a standard agenda item? Now you know why.)
  • Do Less bragging and less blaming and counter it in team interactions so that it does not squelch preferred behaviors. Any advantage you desire to achieve to appear more competent by bragging and blaming works against you in reality.

Managing the amount of thanking, apologizing, bragging and blaming turns out to be a powerful tool in your tool set.

Before hearing the results of the study, would you have anticipated that appearing warm was more important than appearing competent in such social interactions? Would you have managed these kinds of interactions as recommended above?

Posted on: March 20, 2019 11:50 PM | Permalink | Comments (10)

Eye on Trust: Openness

You may have heard, like I have, that openness can build trust. But what kind of openness exactly? Certainly, you can share "too much information" about yourself. You can share the wrong things. That would not help build trust necessarily. It may make things worse, in fact. And there is confidential information you are provided about a project that you cannot share.

So, the question remains, exactly what do you share to build trust with openness as a project manager? Paul Zak, the expert who studies these factors in the workplace and whom I mentioned in the last post on job crafting, has guidance for us.

The technique of openness is how you share information broadly throughout your team. Your actions should enable the project workforce to see that you are providing needed information in a timely fashion without being manipulative. Here are some ways to do this in your weekly team meetings or daily agile meetings.

  • Early in the project, paint the big picture about project savings and value to the business.
  • Include a specific point where you give updates on what you have heard from reliable sources about what may be happening, about what leadership is thinking about any changes to the foundation to your project for example.
  • Roll out information on risks, update on resolving issues, status of action items you or others are completing. Explain how the work does or does not affect them directly.
  • Help a downstream project team get a head start by making upstream information a little early.
    Example: Make draft versions of the BRD available to designers and developers. Sometimes project teams seem to see themselves as artists who must not show their work until it is final, but you can calm them by stating to the downstream teams all the warnings about making assumptions on unapproved versions. 
  • Actively go after useful information from your sponsor. Your communications with your sponsor should not just be you providing updates, but you should collect useful information to pass on to the team. Keep a list of questions that you rotate through when you speak to the sponsor to confirm
    • assumptions are still the same
    • scope is still the same
    • if expectations are still the same
    • If there is any news about the project or program
    • if the priority is still the same
  • Include stakeholder updates in your meetings that go beyond the basics. Remind participants of the point of view of the stakeholder, for example: priorities, desired dates for key events, desired level of participation in routine work and anything else that will improve interactions between the team and the stakeholder.
  • Stakeholders can provide additional information on upcoming obstacles and conflicting activities.
  • You'll want to then check on what part of this information you can provide to the project teams and then plan to provide that information in your next meeting. In your team meetings, you can explain how these impacts the project. Team members can then respond appropriately without it being an emergency. You can see how team members will trust you more.

You don't have to be a project manager too long to hear things like

  • "Our team does not have the ability to adjust to this latest added effort the way you are requesting."
  • "I'm just hearing about this now and will have to get back on you with how it affects our work schedule, but there is going to be a significant delay."
  • "Seems like we are always last to hear about these changes and then are asked to immediately squeeze more work into less time."

These comments are signs that workers do not have a good reason to trust you and the process, and if they do not have trust they will not be engaged or able to participate fully and give a little extra when needed. They are headed for burnout.

When you don't check for useful information you leave out opportunities to build trust, and then you do not have trust when you need it. So, create your standard agenda or meeting preparation checklist to include sections on

  • Sponsor updates
  • Stakeholder guidance
  • Organizational news from reliable sources/peers/PMO/functional organizations
  • Risk management updates
  • New draft versions available and how to get them

You can think of your own ideas that fit in your situation.

When project team members understand that they are getting a broad communication of information, they have more trust in the work environment where they work. If we get this right, he explains that trust improves engagement and engagement improves performance in your project.


What has been your experience in work cultures where there is more openness or where information is more restricted?

Posted on: January 20, 2019 11:02 PM | Permalink | Comments (10)

Getting Those Approvals

This blog is about managing a project workforce. Stakeholders are not treated as a formal part of your project workforce, but maybe they should be at times.

When should you consider them as part of your workforce? When they have simple tasks that need to be completed. A common example is the project document approval task. (Simple?  Maybe in theory!) This is where you run into delays.

Day 1 (Project Manager):  "Please approve linked document in 10 days"
Day 10 (Stakeholder):  "Has Compliance approved?"
Day 11 (Project Manager):  "All other approvers have now submitted their approval. Please approve in 2 days."
Day 13 (Stakeholder):  "This is the first time I have seen this document. The version table is incomplete and there are misspellings. A paragraph is confusing in the Not in Scope section."
Day 14 (Project Manager):  "Versioning updates and spelling edits have been made. Clarification has been added in the Not is Scope section. Please approve the new version in 2 days."
Day 16 (Project Manager):  "Will you be able to approve the document today?"
Day 16 (Stakeholder):   "Thank you for your message. I will be in Aruba for the next two weeks and will respond when I return."

In project manager bars, where they drink the Release on the Rocks, this is a hot topic. How fast do you expect approvals in your organization? 3 days? 1 week? Two weeks? A month? I'm sure many of you Alert Readers have experienced extreme delays for approval at one point or another. If not, then you have just missed out on one of the fun times a project manager can have.

Here are some of the realities you must consider:

  • Environments where certain stakeholders are so busy that they cannot approve documents in a timely fashion
  • Environments where slow approvals have been part of the culture for so long that groups scheduled to receive the docs refuse to apply any resources on actual work until the document is received in fully approved form. And they will raise an issue if it is not received. (You cannot fault them for this.)

So it behooves us to come up with a list of tactics to avoid or handle this type of environment and the subgroup of stakeholders who do not approve in a timely fashion. Some of these you may think about doing but do not actually do.

Avoiding Delays Through Better Preparation

When you create your agendas for stakeholder meetings, be sure to explain:

  • The importance of timely approvals to meeting the timeline and getting the benefits they want.
  • That there will be at least a couple of weeks of warning prior to completion of the document. In addition, plenty of time will be provided for approvals once submitted (1 week, 2 weeks, or whatever is appropriate in your organization)
  • That a delegee should be assigned to approve if the stakeholder is away and cannot review and approve the document
  • That plenty of time will be given for availability of document during development.
  • Make it clear that you understand the importance of what it means to approve. You as project manager will make sure that the content has been fully discussed by a broad group of representatives before submitting for approval (remove the fear).
  • That questions should be asked prior to final day so that response can be provided in plenty of time and still meet the approval deadline.

Example:  At the initial stakeholder meeting (or an early one), include bullets representing statements above and any related that are appropriate to your project.

Beyond the stakeholder meeting, there are other things you can do:

  • Provide a list of the documents needing approval by stakeholders. Another way to reduce surprises and CYA (Cover Your Anatomy).
  • Review any ordered list of who is required to approve first and last (if using) and ask if any changes need to be made.
  • Do not ask publicly if any stakeholder foresees problems with approving in a timely fashion. This may be politically sensitive within the group. Ask that question to individual stakeholders, especially the "usual suspects" who routinely are slow to approve.

Work Planning for Better Preparation

  • If you work in a very challenging environment, consider adding to your project management plan or equivalent document, include some treatment of approvals. A couple of options:
    • Write an assumption that document approvals will be completed in the reasonable amount of time allotted.
    • Write an initial risk that documents may not be approved in a timely fashion and that this may cause delays or problems with resource management.
  • Assign enough time for serious editing to head off any specious reasons for non-approval so additional time can be gained. Get rid of

    • Misspellings / bad grammar
    • Mis-numbering or omissions in content (such as required fields left unfilled)
    • Differing format
    • Incomplete versioning
  • Help your project workforce to manage towards dates for key project management deliverables that need approval, such as the requirements document. Distribute drafts to interested parties, incorporate the feedback and set up plenty of review meetings.
  • Use the automated approval technology available to you, via web sharing system or other document management system, but practice using it if you are new to it. Practice learning its behavior with an internal team and an example document. Especially useful is any feature that allows you to choreograph the chronological order of those who must approve.
  • In your workplan, incorporate plenty of time for approvals. Don't just lump together "Complete XYZ document". For example, include separate tasks for requirement gathering sessions, stakeholder reviews of near-final document, and approvals.
  • Document which stakeholders attend each review session versus who was invited. You may need this information as objective evidence of how easy you made it when you get push-back on any approval. Reduces the need for escalation or makes escalation more in your favor.

What are some other techniques you use? Different environments need different tactics, so let me know what you have found successful. Do you have a problem with missing your chance to do these things and then having to suffer approval delays yet again?


Posted on: June 20, 2018 10:52 PM | Permalink | Comments (20)

Conformity's an obsession with me.

- George Costanza