Who should create the task lists that people use at work? Should a manager, or should each person be allowed to create their own list?

These are questions asked in a blog post today by Seth Godin:

“If you made the list instead of just obeying it, would you be a more valuable member of the team.”

A task list is generally not an isolated set of to-do’s. A task list is a specific slice of an overall project or process. Its the slice that’s relevant to the person responsible for getting those things done.

If each person made up their own task list, it would impossible for a team to function together or for a group to get a larger project done.

But, individuals can be a powerful force of creativity. Individuals can provide new ideas on how to get things done.

A good manager can unlock these ideas. A brave individual can propose these ideas. And a healthy organization has a culture of communication that promotes speaking up.

There are few things more frustrating to a project manager than team members who do not communicate. Non-communicators can single-handedly eliminate a manager’s visibility on a project and be a source of unforeseen, and therefore, uncontrollable risks.

Within this group, the most frustrating are those that ignore direct requests for information or who only talk when they feel like it.

• To the extent that a project manager can pick their own team, non-communicators are generally the last people picked.
• To the extent that a project manager can influence HR decisions, “better communication skills” is the area of improvement most often recommended for non-communicators.
• To the extent that a project manager can limit a non-communicator’s participation in a project, they will.

But when it can’t be avoided here are a few tips to managing a non-communicator on a project.

Find the communication medium that works best. Some people respond to phone calls, others to emails. Some respond to instant message and some prefer talking one on one. Find the medium that works best for that person and stick to it.

Experiment with Non-Traditional Ways of Communicating. All of the above mentioned media are conversations or openings for a dialog. They are in a question/answer or solicitation/response format. Some people simply don’t work that way. Get creative in finding other ways of getting information that don’t involve a “conversation.”

For example, I’ve worked with non-communicators who are best at giving information as it directly relates to the completion status of a task. Instead of asking how things are going, I’ve found it more valuable to assign a task in a project management tool and let them indicate its status. The options I set in the project management software are simple: done or not-done. To maximize the value of information from this technique start with the most detailed level of a task you can find. Think of it like 20 questions where the person can only answer yes or no. Make each question (or in this case, task) count.

Be Patient. People have their own time lines when it comes to answering questions. Don’t mistakenly categorize someone as a non-communicator just because they take a long time to respond to you. I know some people that take 10 minutes or more to respond to a question on instant message. It can be very frustrating when you are expecting an “instant” answer on “instant message” and instead, get a response 10 minutes later.

Sometimes, people are thinking about the answer. Other times, the answer might be more complicated than the asker thinks. Learn how long it takes people to respond and budget in the appropriate amount of time.

Know How to Get Information When You Absolutely Need It. The corollary to being patient is to have a clear way to get information in an emergency. For example, call the person on their cell phone or go directly to their desk. This requires that the project manager prioritize their information need or, at a minimum, have a clear understanding of when to really bother someone. To be effective, use emergency procedures sparingly or, like the boy who cried wolf, it becomes just one more thing the non-communicator doesn’t respond to.

Be Persistent and Consistent. Make sure you get answers to the critical questions you ask. Make it easy for a non-communicator to distinguish between hearing your communication and needing to participate in the communication by providing information.

In the best case, by finding ways to get the information you need from a non-communicator you can potentially find a new, more productive way to make use of their skills on your projects. And if that doesn’t happen, you can at least reduce unforeseen risks to your projects and increase visibility.

A client came to us asking why he never got what he wanted from his project team.

Here’s The Replay of every project he requested.

1. Before a project began he would carefully explain the deliverable to the project manager. He would go into great details on all the intricacies that he’d worked out from months of thinking about the project.
2. The project manager would take notes and send him a specification detailing the whole project.
3. The client would think about the project some more then give the pm the green light to go ahead.
4. The project manager would set-up a schedule and deliver on time.
5. The client would take one look at the final product and inevitably be disappointed. Then frustrated. Then downright angry.
6. “That’s not what I wanted!” he would exclaim. Every time. Months of thinking about the new deliverable wasted. All his plans for using it, gone.

Needless to say, he was frustrated.

The Investigation

I went in and investigated. The process sounded alright. No glaring holes in a typical waterfall approach.

The client had a well-defined goal. The project manager was listening and delivered on time. So that’s not where the break down was.

I could recommend that the client check in every once in a while to see the actual deliverables themselves while they’re being produced. But I know he’s not that kind of manager. Besides, it wasn’t the details that were off in the final product. It was the whole thing.

I started asking the client different, seemingly obvious questions. Then, I found my answer.

“Did you read the specification the project manager sent?”

“No,” was the answer. And that was the answer.

He said it was a big, detailed document that looked thorough enough.

Gauging by the weight of the spec he was sure the project manager had the right idea.

“Besides,” he continued, “I explained it well enough for anyone to understand what I was talking about.”

In his mind, the idea was so clear and well formed that with a careful explanation it should’ve be obvious. The problem was that it was only clear in his head. He’d been the one living with it for months. He’d been the one who saw every detail. But someone it didn’t translate. A critical component of the communication in the requirements gathering phase was missing.

Communication is more than getting out everything you want to say about something (which is what he did). Communication is about making sure the other person understands.

The Core of the Problem

To come up with a solution we needed to get to the core of the problem. Knowing the people involved, the solution wasn’t simply to tell him to read the spec. It would never happen. He needed a solution where he could get what he wanted but without having him

a) do something he’ll never do or

b) change the way projects are done (e.g. adopting agile or requiring more interaction with the project team).

The core of the issue was that the specification was the wrong tool for the project manager and the client to use for their communications.

In general, a specification is the right tool for the project manager to use with his team. The project team needs a detailed blue-print. It also helps the project manager m think through the specific requirements of the project.

But it is the wrong tool to use with the client, particularly this one.

The Answer

I recommended that the project manager give the client a bullet point list of the general features. Keep it to one page whenever possible. This could even be a milestone view of the project schedule with all the sub-tasks rolled up.

If it’s too general, the client will ask questions. And it’s exactly the questions that you want to encourage. Sparking communication is one of the main goals of this approach.

A bullet-point spec is easily digested and easily scanned. It keeps the client engaged. It makes the project manager look like an efficient problem solver and good communicator. Whereas a big specification document can create the impression in the client’s mind that the project manager needs 30 pages to say what the client can envision clearly in a single image or a short conversation.

They tried it. It worked.

It didn’t happen overnight. But, it did work.

Moving to a bullet-point specification set-up a process of iterative conversations that resulted in the client and project manager connecting better and connecting more often.

This resulted in the client getting more of what he wanted, every time.

The requirements phase became a valuable, two-way conversation, rather than a hand-off of responsibility which left the client hoping he’d get what he wanted.

Milestones and sub-tasks are a powerful tool-set to improve communication on projects.  When used together in a project schedule you can consolidate the informational needs of the client, project manager and team without having to use multiple project management systems or spreadsheets.  It allows the schedule to be a single point of truth, as it were, and single reference point for project communications.

Here’s why it works.

People involved in a project have different informational goals.

• The client wants to know when things will be done and how they are progressing.
• The team wants to know the specific tasks they have to do.
• The project manager wants to coordinate the work, meet deadlines, manage resources, spot problems and improve processes.

Without a reference point, each person has trouble communicating. The client demands to know what’s going on. The team explains it in terms of the specific tasks. The project manager tries to translate between the two, or complicates matters but bringing out a Gantt chart, dependencies, a critical path or other project manager specific tools. The end result is frustration (or an exhausted project manager).

Here’s How to Do It.

You can avoid all this frustration and improve communications by creating a schedule using milestones and sub-tasks.  The milestones are the major deliverables or key points for the client. They are what the client wants out of the project and places they need to be directly involved. 

For the team, think of Milestones as parent-tasks and create sub-tasks underneath them. The sub-tasks are the specific, detailed, tasks that the team needs to do to get the project done.

When speaking to the client use the rolled-up version of the schedule showing the milestones only.

When speaking with the team use the drill-down version of the schedule showing all the sub-tasks.

This schedule then becomes the single point of truth, or reference, for all communication on the project. It has all the details needed for the team and a rolled-up view for clients.  The project manager can use it manage the project and facilitate communication without double-entry of data into other systems.

When something changes on the project you can use this schedule to show how the change impacts the milestones (for the client) or the sub-tasks (for the team). 

Taking it Further

Here are a few ways to use sub-tasks to create even more specific information that can improve communication on projects.

1. If your project management software has the capability, you can sort the sub-tasks by each team member or by due date to provide specific to-do lists for each person.
2. Using the same capabilities, you can create custom lists for your clients of all upcoming milestones in the next month across all projects.
3. Depending on the number of people involved, you can use multiple levels of sub-tasks (e.g. 6.1.2) to further categorize project information for different teams or departments that may be involved.
4. The multiple level of sub-tasks can then be rolled-up, as needed, for department meetings or meetings of team leaders.

This question is central to project managers and clients.

Its a tough question because every project has its own unique characteristics. Even if its something that you’ve done before, many factors can throw off a schedule.  As a friend of mine says:

Its not the stuff you know that throws you off. And its not the stuff you know ‘you don’t know’ that throws you off -you can cover that by doubling your estimate or so. Its the stuff you don’t know that you don’t know that can throw you off, 5x or more.

Nevertheless, an estimated due date is a reasonable thing to ask for.  In fact, it is critical to successfully scheduling work, achieving goals and managing people.

So, what’s the best way to answer the question?

First, understand that a due date is a best guess of how things will turn out.  It should be based on the most accurate information available like:

• past estimates of the amount of work tasks took
• past estimates of the calender days tasks took
• comparisons between those estimates and the actual data from past projects
• familiarity with the strengths and weaknesses of the project team and
• the current resources available for the project.

But when you present the schedule to your client, frame it as a basis for communication.  Let them know that, while based on the best information available, it is not a definitive prediction of the future. What it does do, though, is become a definitive guide for you to provide them updates on the schedule and for them to ask for the status of the project in very specific terms.

Second, carefully understand the constraints at play on your project. Every project has at least three constraints:

• Time,
• Money and
• Scope - all of which should center around
• Quality.

Explain to your client that each of those constraints directly impacts the others.

If your client requires a hard deadline, you need to have the right amount of resources and a limited scope. Your ability to meet deadlines further improves if you can scale up the resources allocated to the project to meet unforeseen challenges or pressures on the scope.

In any case, it is the project manager’s job to help control these factors and, most importantly, to communicate to the client how changes, challenges and surprises impact the estimated due date of a project.

Communication is one of the biggest challenges in project management.

Its bad enough when a project manager has trouble communicating with the team that will be doing the project. But it can be down-right dangerous for a manager when there is a lack of clear communication with the project sponsor the person who navigated corporate politics to get the project approved.

The problem stems from not understanding what each person is looking for or unrealistically expecting the other party to speak your language. This can be aggravated by the project manager’s insistence on using only the project management tools which suite their needs, regardless of whether the project management solutions generate the kind of information the political sponsors of the project are looking for.

Read the rest of this post »

Here is a rough translation of an internal memo to Hiro Nakamura (from NBC’s new television show Heroes). It is from the project management office of Yamagoto Industries.

While the PMO has been enthusiastically trying to recruit Hiro for a project management job, the memo points out two areas where Hiro needs to improve his project management skills.

These are lessons all project managers face.

Read the rest of this post »