Eye on the Workforce

by
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

RSS

Recent Posts

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

Eye on Trust: Openness

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)

Eye on Trust: Job Crafting

At some point, you have certainly thought about the importance of trust in project management. Did you happen to think of a lot of ideas to build trust? Probably not. This is a difficult topic.

Lucky for you, researcher Paul Zach looked carefully at workplace trust for 8 years and has developed 8 building blocks you can use to develop your own tactics to improve trust in your project. Some of these tactics have been discussed before elsewhere especially in this blog, but there are a couple that have not been discussed often related to project management. These will be the topics of this and the next post.

Facilitate Team to Craft Their Own Jobs

The first of Zak's building blocks to consider is called "Transfer." The term "transfer" for our purposes represents job crafting, which includes allowing people to use their own techniques to complete their work. That is, they determine how they meet the quality expected of their work.

This tactic is typically presented in training for managers and will always be easier for managers to implement. But that should not let you as a project manager miss out on a tactic to build trust.

Here are specific examples of how you can use the transfer/job crafting technique in your projects.      

  • Help them reduce the scope of existing tasks (when you can't really reduce the number of tasks in your plan) by allowing them to start involvement later during the duration of the task. Using reporting as an example, a team does not really need to report weekly until they really start significant meaningful execution. Similarly, they can fill out templates with only basic, absolutely required information.
  • Assist them with completing their plan for this by answering questions they have.
  • Keep this "crafting" process alive during the project. Provide feedback on how their work in job crafting is functioning. Proactively ask if they need any assistance working it out. Provide positive reinforcement for successes.
  • Consider also individual skill and career development. Ask if there is any special development experiences the team lead is looking for. Add that into work planning.
  • To your own monitoring activities, note participation and successes of project team leads and workers. During closing phase, send out formal appreciations that can be used in performance reviews.
  • Do the same with new team leads as they roll into the project in later stages.

Look for other barriers to flexible work that you can eliminate or reduce.

  • Enable more job crafting by allowing remote work or alternate team work spaces.
  • Reduce required attendance at periodic/routine meetings to individuals who are absolutely necessary at each event. Send good notes out to all others.
  • Remove work rules that are really just part of organization culture and not otherwise justified, such as expectations that a multitude must approve certain documents.
  • Allow use of agile techniques to allow teams to collaborate more even if those techniques are not yet accepted by the organization.

Once you have team leads crafting more of their own work to fit their circumstances, you will have built more of your foundation for a trusting work environment. Do even more by helping them provide the same flexibility to their own workers.

Giving control like this is a key part of maintaining trust. Wresting control away from workers, by forcing restrictions and requirements for whatever reason, serves to break down trust. Be aware of obstacles to flexibility as well.

Next month, my post will be about openness, another one of Zak's building blocks that can be applied to your projects.

In the meantime, have you had success with job crafting?

 

Posted on: December 23, 2018 03:42 PM | Permalink | Comments (8)

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

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

"Thus the metric system did not really catch on in the States, unless you count the increasing popularity of the nine-millimeter bullet."

- Dave Barry

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events