Five Cool Things to Know About Action Items
This post provides some insight into something that exists on every project of any appreciable size - Action Items. A unique aspect of project management, Action Items cannot be planned, but we need to plan for their inevitability.
We cannot plan for specific action items, but can plan for the resources - people and systems - needed to handle Action Items. Our planning is an attempt to foresee as much as possible - and plan for it accordingly - but Action Items are generally the small but important details that arise at the ground floor level as we proceed with the project.
As the name implies, Action Items require action! While they vary in criticality, they usually require action because they must be handled in the short term in order to proceed with planned items. As such, the key planning for Action Items is to ensure your project has the resources that you will be able to assign to them as they arise.
Resources for Action Items include people - but also include systems. In contract to the guest blog post below, I think that all Action Items should be tracked separately, whether trivial or non-trivial. I would be concerned about adding an Action Item to the schedule, since it could represent a change to scope. Action Items are usually be part of an existing task, and will effect that task accordingly.
Here's the TenStep guest blog post "Five Cool Things to Know About Action Items":
An action item is an ad-hoc work activity that requires follow-up execution. By their nature, action items normally cannot be planned for in advance. They arise on an as needed basis during meetings or as a by-product of working on something else. There is no Knowledge Area in the PMBOK Guide for managing action items, but they can be important to the smooth running of the project. By their nature they generally fall under time management.
1. An action item is assigned because there is not enough knowledge, expertise or time to resolve the item at the time it originally surfaced.
2. Action items need to be assigned, worked on later and completed. (If they are not going to be completed, they should not be called action items. Instead, simply note that the item will not be completed.) Examples of action items include forwarding specific information to someone, arranging a meeting and providing a quick estimate on a piece of work.
3. Sometimes an action item is established to investigate an area where there may be a potential problem. Because of this, action items are sometimes called "issues". However, this is not right. An issue is a problem which will have a detrimental impact on the project if left unresolved. Issues are not the same as action items.
4. Trivial action items may be tracked and managed with a standalone Action Item Log. If the action item came from a meeting, you can create a section in your meeting minutes for action items. These trivial action items are usually less than two hours of effort and are scheduled to be completed by the next meeting. If you use this technique you can start each meeting with a review of the prior action items to validate that they are completed and then cross them off the list.
5. If the action item is non-trivial (greater than two effort hours) you should add them as activities in the project schedule. A resource and end-date are assigned as well, and the activity is then managed and tracked as any normal schedule activity. This is the better approach to follow, because it keeps the work activities in one place and allows the project manager to enforce the discipline of knowing ‘if it’s not on the schedule, it will not be worked on.’ This approach also allows the project manager to see the impact of the action items on the schedule. For instance, you may have a small action item that is 4 hours of work. If you assign this action item to a person on the critical path, you will see the resulting delay to your project. This may result in you assigning the action item to someone else instead.
In many cases, action items are trivial in nature, but in other cases they can require substantial work to complete. Projects tend to generate lots of them and you need some method to track and close them to ensure the project work continues to run smoothly.