Project Management

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

Stay Confident for Awkward Communications

Leading by Listening (Part 2)

Leading by Listening (Part 1)

Lockdown! Just Like That Everything Changes (Now You Lead)

Project Site Design for Stakeholders (Part 2)

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

Keeping Requirements Outside the Project for Productivity

Recently I wrote an article with a couple of ideas for tweaks to the waterfall method that makes it a little more responsive to business needs and possibly a little less stressful for the project team. One was to overlap phases and the other was to break up project scope into smaller bites and run smaller projects more often.

I mentioned a third option that would be covered later - and this is it!

First, though, let's deal with a basic preliminary question. What does this have to do with workforce management, the subject of this blog? Managing requirements well is a predecessor to managing the project workforce well. When requirements are clear, stable and complete, your project workforce deals with fewer problems in later phases. Your workforce is more productive generating fewer risks and issues.

With that known, consider now a common occurrence: A project is initiated and eventually a requirements document is created. Think about this a second. The project starts, meaning it is assigned a high-level scope, an initial budget and expected timeline, and only then are actual specific requirements defined. We all know that when details are defined, there are all kinds of discoveries. Some of these discoveries lead to additional expense, duration, dependencies, and resources. Some discoveries force the requirements definition itself to be extended unexpectedly.

What if requirements were handled a different way? What if they were managed mostly outside of the project itself? What would that tactic be called?

Keep Requirements in a Separate List to be Processed Continuously

Consider the situation of a web site that is used by customers. The customer service group and sales group that support the site are endlessly looking for improvements. They want one function faster, another function upgraded, a third function added. They have these needs all the time, not just when a project is in progress.

Why don't they keep a list on their own?

Once they have such a list, they can assign priorities to the items in the list. They can add impact ratings, where the improvements that will bring the business benefits will become more obvious. They can add an indicator to show whether the listed item is new as opposed to "mature" or "stable" (better understood, articulable and justifiable by groups keeping the list).  

All this kind of information is their own decision. No project is needed to manage it. Even better, the groups who keep this list can filter on the mature/stable items, then choose high impact/large benefit items and use that as the basis for the business justification for a project.

The groups maintaining the list may not know the true cost of getting the work completed at this point. For example, they will not have contacted the technology group for sizing. But with a very precise and mature list, sizing will proceed quickly.

In the project, scope (based on the requirements selected from the overall list) is already in a near-complete state. Requirements gathering is much less risky as the business requirements documentation is built out quickly. Additional related requirements ("non-functional" for instance) can be added relatively quickly from control partners like legal, compliance, operational risk management.

Want to level up? Assume that the decision has been made as well to abandon large annual projects and to go with smaller continuing projects that have quarterly releases, as discussed in my article. Each project can take a subset of the requirements, basically taking the highest priority at the time, creating a continuing flow of the most needed functions being released.

Now that is managing requirements for better productivity!

Posted on: November 20, 2018 10:30 AM | Permalink | Comments (11)

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

Planning Around Scarce Expertise (RPA & OCM)

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

Communicating the vision and the schedule were the two organizational change management success factors covered in previous posts. They are very important pieces in the change puzzle. But let's get a little more practical. Successful change management also requires having the right project resources with the necessary skills in time for project start, does it not?

Here are two scenarios that you could encounter in an RPA situation. One is what might be experienced in a group new to RPA projects. The other is what might be experienced in an RPA shop that is a little more mature. Each illustrates the importance of managing project resources to the success of the organizational change as a whole.

In an organization just starting out with RPA, preparing for the first project, few or none of the resources may be familiar with agile methodology or the general process for short RPA projects. The resources are not fully prepared for their roles. Training and preparation activities delay the start of the initial project and likely the end of the project. Leaders, expecting fast financial results as per the business case for RPA, are suddenly questioning the RPA group's ability to execute. Non-supporters in the general organization's workforce suddenly see a reason to become more vocal against the RPA-based organizational changes in general. The new RPA is team is frustrated that they are off to a bad start and will not find it as easy to drive forward in an environment of skepticism as they would have had if they had better managed resources.

Avoid this scenario with more precise planning. You must avoid underestimating how fast you can produce a ready team.

  • Use "left to right" schedule planning for this. Include all activities, especially because you may need to justify a long period before the first project can begin. Think you can produce a full task list? Be sure to add these: expertise gap analysis, create job description for brand new specialist role, recruit needed specialists, interviewing, hiring, wait for background checks, wait for other HR activities you're not sure about but always cause delays, orientation, special new RPA training, team formation. Remember that RPA teams are small. Every unfilled role is a critical problem.
  • Make a conservative estimate as to the time it will take to obtain and prepare the specialized resources you need. Don't even think of scheduling your first project start until all activities are completed.
  • Create a contingency plan for not being able to find the expertise you need. For example, you may have to identify and poach expertise from other organizations. You may have to wait for someone newly trained to get up to speed. Either way, alternatives will take a little extra time and attention than using the standard recruiting group.
  • Consider delaying certain communications about project start if you are not sure of being able to execute on your resource plan. Treat as a high impact risk.

The second scenario is when you are in a more mature RPA shop (as in the Establishing Phase as described in the presentation), you cannot hire new resources with the necessary agile or RPA expertise causing a set of projects to be delayed before they really get going. Organizational leaders, made more hungry by your initial success, desire the same cost-saving benefits coming at a faster rate. They are frustrated by your lack of ability to scale operations.

The point when you start to scale up your RPA operation is significantly different from when you have one or two teams.  (Refer to presentation for details if you like.) The problems with resource management are multiplied.

  • Include in your scaling up plan a tightly-bound recruiting function. Use the corporate recruiting function if you have one. Spend time training these recruiters on what skills you need and why. Describe the needs of your small teams and their short intense agile projects.
  • If you have to use outside recruiters, do the same but also remember to meet often to provide feedback on quality of candidates. You need to get what you ask for. The timing is also important so provide feedback on how fast they are finding experts. Use their info to set expectations on the rate of scaling your team. If you can't fill a role, the whole team has to wait. Your schedule must be set accordingly.
  • Don't suggest to leaders that you can move faster than you can clearly prove through action. We are in a time of high growth for RPA work. That can easily lead to a shortage of talent when you need it. Set expectations accordingly - with everyone involved.

Making sure you have the resources you need when you need them to complete projects is always important for successful organizational change management. With RPA, a new, fast-growing specialty, resource availability presents a significant risk. Don't it be your weakness.

Note:  There will be resources that are not involved in specific project work that will need to be covered by an organizational change plan. These will be covered in other Change Management posts.


* 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: December 29, 2017 02:07 PM | Permalink | Comments (12)

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

"From the moment I picked your book up until I laid it down I was convulsed with laughter. Some day I intend to read it."

- Groucho Marx