Have you ever been asked “how long does the task list need to be?” If so, has this struck you as code for something else?

When I’ve been asked this question, I’ve sometimes thought it was genuine, but just as often, I’ve sensed that the questionner is wondering when the other shoe is going to drop. In other words, he or she was actually wondering: how heavy will the burden of project management have to be? S/he sees someone calling themselves a “project manager” and s/he thinks the person is poised to impose a bunch of unnecessary and heavy-handed layers of red-tape.

I am sympathetic to this perspective. Maybe the reason is that I spent some formative years of my career studying how people actually do their work. Most of us don’t like busy work, and we don’t like having to submit reports or fill out forms just for someone else’s benefit.

The antidote to this situation is twofold. First, start from the ground up. That is to say, allow the project and program tracking artifacts and mechanisms to emerge from the team that is using them. This is the approach that Jennifer Vinopal described to me on my recent trip to New York University’s Bobst Library. Vinopal is the Librarian for Digital Scholarship Initiatives and Project Manager for NYU’s Digital Library Technology Services. She is gradually introducing a basic project management office capability a little bit at a time, as staff can see the benefit of putting in the time to submit the data. This shows a real understanding of how to introduce lasting change.

A second thought along these lines is my answer to the question with which I started this post: how long does the task list need to be? In my view, the task list, or even it’s big brother, the work breakdown schedule (WBS), needs to be only as long or as detailed as required to understand the status of the project. This is the main–and most important–purpose of the task list, and the WBS: progress monitoring.

This means that there is no one level that is right for every project, nor is the level necessarily going to be the same throughout the life of the project.  It helps to ask some questions: how are the team members finding out when and how work is getting done? Often, they are waiting for certain tasks to be completed before they can start or finish certain other tasks, so this is important information. How do they want to find this out? At what point in their workflow? Can you adjust meeting schedules and select project tools so that when you meet your information gathering needs you also meet their information gathering needs? It may not be completely possible, but it’s worth trying for, and you may be able to improve on practices that are not taking team workflows into account.