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.
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.
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.
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.
Look for other barriers to flexible work that you can eliminate or reduce.
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!
We continue with the important topic of persuasion, giving you more and better ways to use the "persuasion tool.".
Here's a situation for you and a question:
You have to ask one of your team leads for an updated work schedule after a requirement was adjusted. Because of the decision meeting schedule, you need the update more quickly than will be comfortable for the team lead. You recall that the same team lead has rejected your requests the last couple of times. So should you expect better treatment this time or the same treatment as last time?
It's better to know in advance so that you can customize your approach. You don't want to take the wrong tone or say something that will make getting the information in a timely fashion less likely.
Use Previous Rejection to Your Advantage
Research was actually done related to this and the verdict is: Someone who has rejected you previously is more likely to grant your request. Perhaps it is because they are guilty from turning you down the first time. Doesn't really matter to you, actually. Make your request confidently, even if you have been rejected multiple times before, because the odds are in your favor.
Remind Target of Their Control
Unfortunately for us project managers, like the situation above, we are often in the situation where we can request that a task be done, but the individual we are requesting from does not have to grant our exact request. Maybe they will grant the request eventually, but later than we need. Maybe they meet our timeline for providing information, but the quality of the information does not meet what we really need. We need all the persuasion tactics we can master to drive work to completion.
Ironically, you can be better off if you remind your target of their control when you frame your request. As part of your initial request, not later, you affirm the target's control in the situation by saying something like:
There was a study done to confirm this was true looking across 42 separate previous studies. The tactic worked in most contexts, so definitely try it out when you make one of your more difficult requests.
Express Confidence in Worker Ability to Complete
If you are trying to persuade one or more people to complete a task, not necessarily make a decision, two points are important to get across: your confidence that they can do it and that you are there to support the effort.
Assuming that you have defined what you want, a key motivator is that you have confidence that the worker or team can do the work. Say it clearly using words you are comfortable with. This statement reduces an unspoken concern over potential problems or failure that will result in negative consequences for those completing the task. This concern is always present, and more pronounced in certain environments, some of which you may have worked in. With this tactic, you can be the positive force that helps teams complete tasks in any environment.
What are tactics you use to persuade in difficult circumstances?
Teams are more successful dealing with stress when they have a shared purpose. That was the conclusion reached by studies and reported in my last post. So the question remaining is: How can this information be translated into success tactics for you as a project manager? You have to continuously foster a particular line of communication related to challenges. Here are tactics you can use:
From the beginning of the project, promote its business benefits. The shared purpose will be to complete the project so those benefits are realized.
When hiring workers, start building a high-performance team by selecting people who see project obstacles and challenges as opportunities.
Later in the project, as obstacles appear and work teams are put under stress, remind the team that the benefits depend on successfully completing the project together.
Discuss the challenges the project team is facing. Bring the conversation around to what the project team can do to meet the challenge. Determine how to work together to meet challenges, surmount obstacles and reduce stress. For example:
Do not mistakenly communicate an attitude that appears you want to avoid stress during the project. And don't imply that stress is something individuals will have endure on their own. This does not work. The team must expect to work to meet challenges together, and that will reduce stress overall.
Set up new deliverables like the requirements document as a key part of getting business benefits. Make sure the deliverables mention or link back to the business benefits desired. This not only good practice but helps to link team members together throughout the project.
If key points from the project charter change at any time, use that as a trigger to update the project team on adjustments to the shared purpose.
At the end of the project, as part of Closing, communicate to everyone who participated that the benefits will be achieved because of their participation to complete. This will cement in their minds that working together as a team is superior to other methods. And you will be remembered as the project manager who runs projects this way.
Notice how all these tactics lead to regular discussions about obstacles and challenges. Build up a habit to think in this way. Project managers regularly talk about risks and issues, so this is not a foreign concept. The trick is to communicate that project challenges are not stressful threats, but opportunities for the team to succeed.