Controlling Action Items

Controlling Action Items

Have you ever come away from a meeting with the comfortable feeling that issues were properly discussed, agreements were reached, and general goodwill prevailedand yet you were not sure what was supposed to happen next? In such a case, you know that nothing will happen next.

All projects are the result of actions, and actions are carried out by individuals. It is hard enough to get people to do work that is assigned to them; it is impossible to get them to do work that is not.

There are two types of work to assign: project activities and action items.

An action item is a piece of work that is given to one or two people to be done by a specified date. Action items differ from project activities in that the latter are part of the project plan. Action items are generally small, but they have the ability to cripple a project.

For example, suppose you are managing a project to convert an application from one computer system to another. The manufacturer of the target system has just released a new version of the operating system that will be preloaded on all new equipment orders. You have reason to believe that the application will not operate on the new version without modifications, so you decide to order the target system with the older version.

Someone on your team has read that the new version is tied into the system's firmware and that the older version will not run on a new machine. If this is so, you have a problem, and you all agree that this should be checked out. But unless somebody actually picks up the telephone and calls the manufacturer, this little item will be forgotten until the new equipment arrives unable to run the version of the operating system that you need.

As soon as the issue is raised, you must create an action item. You may ask the team member, or the technology architect, or a programmer to call the manufacturer, or you may do it yourself. It does not matter who handles it. The only things that matter are that somebody does it, and that you make note of it so that you can follow up.

Raising Action Items

Action items are raised continually throughout any project. They come up in meetings, in technical discussions, in client reviews, in hallway conversations, over coffee, and during private reflections. Action items arise from:

1. Assumptions. Someone says, "Well, I assume that ..." or "I think that ... is the case." Unless you have absolute certainty (and sometimes even then), you are hearing something that needs to be checked out. Create an action item and assign it to someone.

2. Doubts. You or some member of your team question whether or not a statement is true. You need to verify what has been said. Ask the doubter to investigate.

3. Tasks. An unplanned task arises. For example, you discover that a new interface card is available that would solve your graphics problem. Create an action item to have somebody check it out.

4. Questions. Somebodyyou, your client, or a team memberasks a question that cannot be answered immediately. Create an action item to find the answer.

5. Requests. Somebodyyou, your client, or a team membermakes a request for material or information or equipment. Create an action item to ensure that the request is honored.

6. Shoulds. You think to yourself, "I should ..." Create an action item or it will never get done.

Tracking Action Items

The only way to track action items is to write them down; you cannot keep them in your head. There are three places to write down action items:

1. The issues log. This is described below under "Reporting Status." The issues log is useful for larger action items, but small ones will clutter it up, and, since it is intended for management to review, you should reserve it for issues that need consideration, not for the simple tasks that constitute most action items.

2. Meeting minutes. Since most action items arise from meetings or are assigned in them, they should be recorded in the minutes.

3. Your personal calendar. Any action items that you take on yourself must go into your personal calendar. You may also choose to note other people's action items so that you have a reminder to follow up. Your calendar is discussed in Chapter 6 under "Managing Your Time."

Action Items and Meetings

If a project meeting does not produce action items, you have probably wasted your time and that of everyone else at the meeting.

2. Doubts. You or some member of your team question whether or not a statement is true. You need to verify what has been said. Ask the doubter to investigate.

3. Tasks. An unplanned task arises. For example, you discover that a new interface card is available that would solve your graphics problem. Create an action item to have somebody check it out.

4. Questions. Somebodyyou, your client, or a team memberasks a question that cannot be answered immediately. Create an action item to find the answer.

5. Requests. Somebodyyou, your client, or a team membermakes a request for material or information or equipment. Create an action item to ensure that the request is honored.

6. Shoulds. You think to yourself, "I should ..." Create an action item or it will never get done.

Tracking Action Items

The only way to track action items is to write them down; you cannot keep them in your head. There are three places to write down action items:

1. The issues log. This is described below under "Reporting Status." The issues log is useful for larger action items, but small ones will clutter it up, and, since it is intended for management to review, you should reserve it for issues that need consideration, not for the simple tasks that constitute most action items.

2. Meeting minutes. Since most action items arise from meetings or are assigned in them, they should be recorded in the minutes.

3. Your personal calendar. Any action items that you take on yourself must go into your personal calendar. You may also choose to note other people's action items so that you have a reminder to follow up. Your calendar is discussed in Chapter 6 under "Managing Your Time."

Action Items and Meetings

If a project meeting does not produce action items, you have probably wasted your time and that of everyone else at the meeting.

If the problem is that the team member dismisses the action as unimportant, make it clear that you require a resolution.

If there are other barriers to completing the action, identify how else you might get it done. Perhaps it should be assigned to somebody else. Maybe the team member is unsure how to proceed and needs some advice or assistance. One common problem arises when team members need to call someone external to the project. Many team members will not persist if the person they are calling does not readily return calls. When this happens, take on the action item yourself; you are paid to be persistent. You may not be able to handle the details of the call, but you can get the necessary parties together.