There are two alternative techniques for assigning work to your team members. The easiest is to assign them activities; like items on a “To Do” list. That doesn’t take much thinking and it’s usually a bit vague. The harder way is to assign accountability for producing a deliverable with acceptance criteria. That takes a lot of thinking because you must specify exactly what you want and how you will measure the team member’s work. Deliverables are always better assignments because the team member will understand exactly what you expect of them, before they start work. People perform at a higher level with deliverables and that is the key to consistent project success. Let’s discuss how to define and assign deliverables. Leading Teams Main Page
There are several components in an assignment. You need an estimate of the amount of work the deliverable will take. You also need to identify the risks in producing the deliverable. A team member often needs to receive work products from others to produce their deliverable. All that information is best stated in a work package. The work package is a one-page document that supports excellent performance because it gives clear assignments to team members. The work package also lets team members participate in estimating the amount of work and the approach to the tasks. But let’s get back to the key element, the performance expectation.
Deliverables versus Activities
There is a clear distinction between project team assignments that are activities and those that are deliverables. Activities are “To Do’s” like “teach the payroll system training class.” Deliverables are end results like, “After the payroll class, 85% of the attendees can enter 30 pay changes per hour.” With each of these assignments, a team member can teach a payroll class. But the content will be different with the deliverable assignment. That’s because the trainer is not just conducting a class. They have a measured result they are accountable for delivering. Project managers who design team member assignments as deliverables have notable advantages over those who use activities. Before listing these advantages, let’s make sure the differences are clear between team assignments made by managing with activities and those with deliverables. Effective Feedback
Project Team Assignments Example #1: Assignment to a Teenager
Activity: “Clean up your room.”
Achievement: “Put all those empty Pepsi cans and candy wrappers in the garbage.”
With the activity assignment, we have only told the teenager to perform an action without defining it. The teenager has to guess what the parent wants. There can be many interpretations of what this activity involves. So it is likely that you won’t get the end result you’re looking for. The key flaw in this (and any) activity assignment is that there is no clear performance expectation. There is no performance standard to measure their actions against. There is only a vague idea of what a “clean room” looks like. As a result, we can’t gain the teen’s commitment to the assignment. And we can’t reasonably deliver consequences for their good or bad performance. Team building
With the deliverable of “all those empty Pepsi cans and candy wrappers in the garbage,” we have the potential for better performance and commitment. The expectation is clear and it is possible to get the teenager to commit to it. If there are still empty can and candy wrappers on the floor after the teen says they are done, they will have to agree that the standard wasn’t met. On the other hand, if they also put their textbooks and computer on the desk, we will have to agree that they exceeded the standard. In this example of a deliverable, any rewards and punishments have a better chance of being seen as fair because the standard was clear.
Project Team Assignments Example #2: Assignment to a Team Member
Activity: “Develop recommendations to reduce turnover.”
Deliverable: “Get management committee’s approval of policy changes that will cut turnover by 10%.”
With the activity assignment, the project manager must continuously check the team member’s work to guide them. That’s because the team member cannot have a clear idea of what the PM wants. (It’s also possible the PM doesn’t know what they should achieve.) The team member doesn’t know whether to develop 200 recommendations to eliminate all turnover or just a few to bring it down a little. This leads to a game of “Did I get the right answer?” each time the team member thinks they are done. The team member does some work and brings their recommendations to the PM asking, “Is this what you wanted?” The answer to this question is usually “No.” Then the PM blames the team member, saying, “You didn’t understand.” So the team member goes back to the drawing board, frustrated and irritated.
The deliverable assignment solves these problems. The project team member knows what’s expected and doesn’t have to guess. The PM has a better opportunity to gain the team member’s commitment and positive or negative consequences will be clear and fair. Additionally, the team member can get a sense of satisfaction from meeting the expectation.
So why do PMs assign team members activities rather than deliverables? The answer is that it’s much easier and safer than assigning achievements. There are two reasons for this. First, by assigning activities, the PM doesn’t have to think through the situation and commit to exactly what he wants. They have some wiggle room to change their mind on what they want. Second, it is difficult for the PM to make a mistake when assigning activities. Only the person doing the work can be wrong. This is particularly devastating for the team member if the PM doesn’t protect them from the sponsor’s displeasure. Weak PMs always use activity assignments because it’s safe for them and always leaves them wiggle room.
Now let’s look at some more good and bad assignment examples. The bad ones are more entertaining so we’ll start with them.
Project Team Assignments Example #3: Counting the Wrong Thing
Here are a few examples of counting the wrong thing on a customer service improvement project. The project scope is defined as “Provide World Class Customer Service that Delights the Customer.”
- A PM measures the engineers’ performance by the number of lines of code each one writes. The engineer with the highest total gets a lunch with the CEO.
- A PM measures the trainers’ performance by ratings the class attendees give each trainer. The trainer with the highest rating receives a certificate of appreciation.
- A PM measures the performance of team members by counting the number of interviews each person conducts. The team member with the most interviews gets publicly recognized at a status meeting.
What performance will the PM get from project team assignments like these? Well, the engineers will write a lot of lines of code and some of it may benefit the customer service division. But a lot will not. The attendees in the trainers’ classes will have a fun time and give the class/trainer a high rating. But they won’t learn much. The team members will conduct a lot of interviews but much of the information will be gathered in a hurried manner and may be useless.
The project manager in these examples counted the activity being performed and got the results he deserved. These activities produced high volumes of whatever the PM was counting, even if it contributed very little business value. The PM most likely did not know what business value the project needed to deliver. So he created assignments that were easily identified activities.
Project Team Assignments Example #4: Counting Only Dates
Another form of counting the wrong thing occurs when the due date or duration is the only metric. Usually, the due date comes from an executive and does not consider the amount of work to be done or the availability of the people to do it. The due date of each assignment is picked to support the entire project’s date. In this situation, the team members have no commitment to their assignments’ dates and they often recognize (even before work starts) that the dates are impossible.
At each status meeting the PM asks, “Are you on track to hit your due dates? You committed to them.”
Most team members give the PM an optimistic thumbs up. Then one day a truthful person says, “No, that date is impossible. There is no way I can hit it.” The PM gets angry and from them on, everyone reports they are on target to meet their dates. They don’t mention that they’re counting on miracles to do so. When the due date draws near, the team members slap together whatever they can and turn it in. It’s poor quality work, but at least it’s on time. The organization then spends months and thousands of dollars to fix it.
Project sponsors drive much of this “due date behavior” when all they focus on is the due dates of team assignments and the project as a whole. This is not to suggest that the dates are not important; they are. But delivering junk by the due date does not make the project a success. In all honesty, most project sponsors are used to projects with only dates for tracking progress. Too many project managers don’t report anything else that is measurable. Everything else is vague, subjective statements. So it’s not surprising that sponsors like dates. They are objectively measurable and unambiguous.
What project managers need to do is to count the right things. They need to count the business value an assignment or a project produces, the date, the cost and the risk(s). These techniques take a bit of time but they yield enormous benefits. Let’s see how you do that.
Top-Down Decomposition to Create a Hierarchy of Deliverables for Assignments
You must work with the sponsor to define measured deliverables for the project scope and the major deliverables leading to it. This includes acceptance criteria the sponsor will use to measure success. Let’s use the customer service project example again. This time the scope definition the sponsor sets is “Complete 95% of customer phone calls within 3 minutes with less than 3% calling back about the same problem.” This is a clear measured outcome. Next, you decompose it (break it down) into smaller achievements that support the scope.
As you break down the scope into its IT system deliverables, you come to the GUI (screen display) that an engineer has to develop for the customer service reps to use. That measured achievement could be “Customer service rep sees 6 months of customer history within 4 seconds of entering the customer’s name or number.” Please note that this achievement is measured in the users’ business, not the IT system engineering department’s business. This is much more supportive of the project’s scope than counting lines of code that the PM used in the earlier situation.
The trainer has a different achievement, too. The assignment could be “80% of the class attendees can answer the top 20 customer questions in 120 seconds or less using the new GUI.” Again, what you are counting is more relevant to the project’s scope than whether the attendees had a good time in class.
The team members interviewing the customer service managers could have a measured business outcome like, “Managers reach consensus on the ten most important customer service problems.”
That sounds pretty straightforward.
It takes some time and good technique but what you are now counting and measuring is relevant to achieving the project’s scope. Project team assignments defined in measured terms like those above make performance expectations clear to the team members before they start work. That encourages their commitment and makes estimating and tracking much more precise. It also lets you spot problems early, when you have a chance to fix them.
Our deliverable-based assignment technique is a key to our Achievement-driven Project Methodology. It pays important dividends in managing projects to achieve successful results. When you assign a project team member a deliverable, you have a much easier time of clarifying expectations, gaining commitment and giving rewards based on performance. All the techniques in this article are part of our private, online training courses delivered over the Internet or as in-person seminars for organizations.