Eye on the Workforce

Ah, the luxury of having an active task with an end date that is far away. You can concentrate on the tasks that are more urgent, making sure the team focuses on getting those done on time. There will be plenty of time to bring attention to that non-urgent task later.

That is, until the day when you think, "Is that task due already? Last check it was only 25% done and now there is only 10% time remaining!"

A long-duration task could be a task that takes many weeks to complete in a project where tasks typically last a week or two. There's been no mistake. It has been scheduled that way. A long design task, for example, to complete a single critical, difficult display for stakeholders. Or a long development task that takes the effort of many specialists who are working part time on the project, increasing the duration, but not the total effort. The key characteristic is that the task has been set a long duration by the team or owner (or you!) and now it is in progress in your project along with many other tasks that have due dates much sooner.

Consider this situation an opportunity, a way to exhibit your more advanced execution skills and maintain focus on active tasks with long durations. Build or strengthen this habit by using certain tactics and staying "above the fray" in your meetings

Stay Above the Fray . . . Inexperienced practitioners can wait too long to start checking on tasks that start weeks or months before they end. You can probably remember meetings where you allowed task reviews in meetings to be all about the urgent. That's what people want to talk about. But long-duration tasks have long durations for a reason. Effort needs to be expended the whole time. If inadequate effort is expended because of overconfidence, distractions or too much time allocated to urgent tasks, then the group completing the task will have lost the opportunity to do needed work.

• Start checking status on long-duration tasks soon after the start date occurs. This forms a habit and expectation in the meeting. All tasks are "weighed" the same.

Use Effective Task Management Tactics . . . Manage long-duration activities to set up task owners and yourself for success. If you wait until too close to the end of the task to start checking in, then you lose the opportunity to intervene.

• Your agenda for routine project team meeting should include Tasks In Progress. In case you can't get to all long-duration active tasks in one meeting, make sure you get a status in the next meeting. Build the habit and expectation.
• Obtain status simply by requesting percent complete. You can gather other information as appropriate for your project and time limitations. You may need to help those reporting to be concise.
• As soon as percent complete drops behind pragmatic expectations, ask questions about whether there are problems. If the report is that time can be made up, check on that over time. Be respectful and positive, but skeptical and careful. Call a risk a risk.
• Provide positive reinforcement when tasks are completed. Workers will appreciate positive experiences from the usual grind of routine task management.
• Consider whether a long-duration task would benefit from being broken into smaller chunks that allow better monitoring of progress. This could be as simple as splitting creation of a large document into a task for "Complete review draft" followed by a task for "Incorporate feedback, complete document and submit for final approval". Work with the owner to come up with ideas.
• When you see long-duration tasks, be proactive about asking the owner or team about expected obstacles to completion. Make a note of these and ask about them during the task status updates.

A big part of keeping project execution on track is keeping long-duration tasks on track. The ability to get these type of tasks completed is a routinely useful skill that you can improve to increase your success and that of the teams who make up your project workforce. And if those who can possibly pay you the big bucks happen to notice, all the better.

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?

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?

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!

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?