How to Improve Your Ability to Define Project Tasks

Written By: Esther Schindler
August 12, 2013
8 min read

It’s tempting. You want to sit down with your favored project tracking tool and begin entering project tasks and the dependencies between them. But control yourself! Before you can enter data, you have to be reasonably certain that your task definitions have the appropriate granularity. If you don’t, you’ll find a whole new world of Ways To Screw Up.

Formally, the process of dividing work into smaller elements is called a Work Breakdown Structure, and there is a particular skill in breaking down project tasks into these right-sized chunks. That skill does not necessarily come naturally. That is, you probably know instinctively that “Build the customer database” or “implement social media” is too big a task to enter into your tracking system; it has to be broken into smaller components that you can identify, assign people to, and track progress on.

At the other extreme, “Paint wall 1; paint wall 2; paint wall 3” is too much detail. In that scenario, a project manager (whether or not she has that title) spends more time updating the tracking system than doing the work. The task completion list doesn’t give a sense of what the team (of 1 or 100) actually accomplished, either.

Let me reassure you: This process of identifying project tasks is something we all get better at with time and experience. But even the most novice of project managers (and team members!) wants to do a good job, so herein I provide guidelines at improving your skill.

To keep this discussion under control, I don’t go into the skill (or art) of predicting how long a task will take. Nor am I aiming to help you decide how many people to put on the project. For that, the ideal answer is always five. Fewer than that and everybody has to do everything. More than five people, and you lose more time in meetings than you gain from collaboration. Or if you want a more elegant function:

Project_length=√sod’s_law +estimated_hours

+((randint(number_of_project_members)*sod’s_law)

Here I’m only concerned with making sure you have all the tasks identified, with enough detail to make them trackable but not so much that you get lost.

Define project tasks in one or two sentences.

That doesn’t mean that a short task definition is ideal (“create the database” is short after all), but that the longer your description, the more likely the task should be broken into smaller pieces.

Describe a task in a sentence or two. Don’t try to make it the same thing as the specification; you’re defining here, not designing. As you start, especially, write this task to be flexible. As you get underway with the project, you may discover an internal structure that implies decomposition into several subtasks.

Look at project task dependencies. What steps are missing?

Before you start connecting the dots to identify the critical path – that is, what events have to happen or the whole project blows up – you should look at your tasks to identify what depends on what else.

Think about dependencies in terms of handoffs: What has to be handed off from one person or team to another? If you don’t recognize you need something to be done by Team A before Team B can get underway (“choose paint color” before “paint”), you’ll bump into problems.

And this reminds you to learn what dependencies the other teams have, as well as their roles and responsibilities. How much does your task depend on someone else’s project being done or arrival of materials? If one or the other is skewed, then you may need to reorder tasks to adapt to those constraints.

For example, you might initially start with “set up the stage, sound, and lighting” for an event. You could estimate the time it would take one experienced person to do the task. But then:

  • If it involves a contractor, you need to get the estimate from the contractor. (That’s another task.)
  • If it involves a task where things can be counted, such as setting up chairs, put in how many chairs there will be. (And where do those chairs come from? Yet another task.)
  • If it involves a machine’s use, such as a label maker, know how long it takes to make 100 labels. (And who’s responsible for acquiring the equipment? How long will that take?)
  • If it involves construction (such as booths), estimate how long it takes to make one, and ensure that each step in that process is in your project plan.

Ask experienced team members to identify the steps, and trust their answers.

In the eyes of many worker-bees, project managers shouldn’t be the people breaking down the work into functional pieces at all. The team members should be given the broad goals and asked to identify the component pieces. “Don’t split things like that; that is not your job,” one person told me. “Let the team do it.”

The idea behind this viewpoint is that the business people and managers can define what they desire, but only the implementers (the lawyers, pool builders, or chefs who perform the work) can optimally break these down into actual functional tasks.

I wholeheartedly agree that you should ask experienced people about breaking big tasks down to smaller ones. But you need to trust their experience. An ace can do it in minutes; a novice may never get it right.

And you may not have the expertise in the team at all. For instance, in the 1980s I was part of a computer user group that decided, “Let’s put on a computer fair!” None of us had done anything like that (if we had, we might have been less enthusiastic about it). So we could create a task like, “Send out press releases about the Downeast Computer Fair” without anyone realizing that someone had to write the press releases and someone had to make sure they were written by a certain date and gosh what would they say? (That’s a perfect example of the earlier point about identifying task dependencies, too.)

Even so, you should certainly get input on task identification from team members whether you’re the boss or just a colleague. With the team’s active participation, everyone understands why things are decomposed the way they are. That permits more pushback on scope creep since more people have the big picture as well as the detailed view. Plus, by involving even newbies in the process, team members learn how to do this for themselves; thus the search for people in the organization who can help another team do it in the future is much less difficult.

Identify project tasks by the time you expect them to take.

Several resources suggest that you should define tasks to be completed in short stints, though I’ve heard varying advice about how long that is. “The rule of two” suggests that “Nothing takes less than two days or more than two weeks” while “the 80 hour rule” advises that no single activity or group of activities producing a single deliverable should be more than 80 hours of effort. I leave the exact number to you, as a result; I’m not in a mood to quibble.

But in defining the tasks at longer time spread, consider the reports you need to provide. Don’t let any task exceed a single reporting period. If you give weekly reports to the client or the boss, then no single activity or series of activities should be longer than a week long.

That’s especially true if your project production is tied to someone’s signoff, which is common for consultants. Quite often, tasks are followed all the way to the client’s invoice and thus must be traceable to requirements.

But even without that: Consider what happens if you define a task that will take a week. If the person to whom you assign the task gets lost, he may not say anything until close to the end of the period (say, five days). Which means that you don’t know things are off the rails until then… and now you’re a week behind.

Identify project tasks by their completion tests.

That is, begin with the end in mind. If you can’t define what “done” means, for the task as well as the project, you’ll never get there.

One way to accomplish this is to talk with your quality assurance or testing team. Figure out how to verify that work has been done using a series of tests. If you can do that, you can measure progress as well as define the specific items for the team to work on.

Ask, “If someone claimed to have completed X, would you know how to test it?” If QA doesn’t know, then the task is too big. If QA says, “This could only be tested in conjunction with Y,” then there’s a good chance that X is too small.

You may not have a formal quality assurance department; not every profession has that sort of process built in. But you probably do have someone in the role of High and Mighty Poo-Bah who signs off on project phases, sometimes in accompaniment with (oh boy!) a check. Give your list of tasks a hairy eyeball and ask yourself, at least, “How will I know when that is done? How can my client avoid paying me by claiming it is not?” If you don’t have a good answer to that question, you probably have more work ahead of you.

“Think like Lego building and how many bricks it takes to complete your design,” one accomplished executive told me. “You will not know everything, so start with what you know and ask for more details. Plus micromanagers want everything; others want to-dos not how to-do.”

What have you found helpful in identifying the “right” size for tasks in your project planning? Share your wisdom in the comments, and we can all get smarter.

Esther Schindler has been writing about computers and business topics since the early 1990s. You’ve seen Esther’s byline in prominent IT publications, such as CIO.com, IT World, and IEEE Spectrum. Her name is on the cover of about a dozen books, including most recently The Complete Idiot’s Guide to Twitter Marketing. You can follow her on Twitter @estherschindler and circle her on Google+, where she will keep you up to date on software trends, her cats, and baseball shenanigans.