I'd looking for feedback on managing Action Items in a log file versus adding each Action Item as a separate task in the project plan. It seems to make sense to add an Action Item as a task since you can assign resources, target date and manage the progress. Has anyone taken this approach? What are pros & cons? Saving Changes...
Bala S DuvvuriProject Manager| ShellBangalore, Karnataka, India
IMO for every action item it doesn't make sense to modify the project plan because once it is approved without proper change management we shouldn't change the project plan. Also you can assign a resource to action item and still track it. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Pro: putting it in your schedule makes it easier for you to control and monitor
Con: you are constantly re-baselining your schedule.
I usually avoid putting them in the schedule unless they are substantial enough and, thus, worthy of going through a re-baselining exercise. By and large, I expect the action item work to be completed within existing schedule activities.
...
1 reply by Patrick Dicey
May 10, 2016 3:16 PM
Patrick Dicey
...
From my point of view I typically see an 'action item' section within a schedule as Level of Effort (LOE) work (some actions may be either overhead or direct) that would not typically impact your project baseline. This is a separate clearly-identified section within the schedule.
With that said, if you're in a highly regulated, audited, DOD-type environment than your customers may not approve having LOE tasks in a network so your customers may force you to use a separate tracking system for Earned Value audit compliance.
If an action turns into a significant task that is within project scope it should be handled within change management process and either assigned to an existing work package (in-scope, planned) or assigned a new work package with budget (in-scope, unplanned work) as others stated. In most cases, neither should cause you to have to re-baseline unless you come across a gross amount of unplanned work (should be rare) or receive a change order to include out of scope work.
Saving Changes...
Anonymous
IMHO it does not really matter; as long as you do not re-baseline. It is likely that these action items are already related to certain activities on the schedule. However, since action items are things that pop up and could be clarifications or issues - I would prefer you include on a log
The main issue with action items and issues logs is not what format or platform you use - it is the timely resolution. To have timely resolution, you must put due dates and assign owners to these action items as soon as they are identified. Saving Changes...
I would also add that depending on the number and criticality of the action items and issues that arise, the management of these could become a high risk item for project success. I have learnt my lesson and started to use JIRA tool for this tracking... I would recommend using a tool if you have access to one Saving Changes...
Melwyn DSouzaPM III| National Australia BankBox Hill, Vic, Australia
My approach is if the task is an one time activity(e.g., engaging a team for specific install/config) then I will leave them in the tracker and if I need to track them in all the SDLC phase, then I will add them to the schedule.
My understanding on schedule re-baseline, that would be required if milestone date moves, else you can amend the schedule and communicate. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
The problem, Melwyn, is not necessarily in your milestone dates but also the budget impact of adding activities to your schedule.
...
1 reply by Patrick Dicey
May 10, 2016 3:22 PM
Patrick Dicey
...
Neither schedule or cost performance should cause a rebaseline, correct? Otherwise, your SPI and CPI will always be 1.0. Those are valid variances that should be reported with root cause and/or corrective actions identified and accounted for in an EAC update.
Managing action Items in a log file is more productive, We can assign a resource to particular action with a completion date to monitor or track the progress. Action log can be a simple Excel work sheet or a tool such as JIRA.
Adding action items to a project plan involves lot of administrative effort,more over re-base lining the plan requires approval of team and or implement a change management process. Not recommended unless the action item is a change that is very substantial and strategic.
I used action logs in Excel format as well as JIRA tracking system and managed well. Saving Changes...
Patrick DiceyManager, Customer Project Management| CentralSquare TechnologiesOrlando, Fl, United States
May 05, 2016 11:57 AM
Replying to Stéphane Parent
...
Pro: putting it in your schedule makes it easier for you to control and monitor
Con: you are constantly re-baselining your schedule.
I usually avoid putting them in the schedule unless they are substantial enough and, thus, worthy of going through a re-baselining exercise. By and large, I expect the action item work to be completed within existing schedule activities.
From my point of view I typically see an 'action item' section within a schedule as Level of Effort (LOE) work (some actions may be either overhead or direct) that would not typically impact your project baseline. This is a separate clearly-identified section within the schedule.
With that said, if you're in a highly regulated, audited, DOD-type environment than your customers may not approve having LOE tasks in a network so your customers may force you to use a separate tracking system for Earned Value audit compliance.
If an action turns into a significant task that is within project scope it should be handled within change management process and either assigned to an existing work package (in-scope, planned) or assigned a new work package with budget (in-scope, unplanned work) as others stated. In most cases, neither should cause you to have to re-baseline unless you come across a gross amount of unplanned work (should be rare) or receive a change order to include out of scope work. Saving Changes...
Patrick DiceyManager, Customer Project Management| CentralSquare TechnologiesOrlando, Fl, United States
May 07, 2016 8:27 PM
Replying to Stéphane Parent
...
The problem, Melwyn, is not necessarily in your milestone dates but also the budget impact of adding activities to your schedule.
Neither schedule or cost performance should cause a rebaseline, correct? Otherwise, your SPI and CPI will always be 1.0. Those are valid variances that should be reported with root cause and/or corrective actions identified and accounted for in an EAC update.
...
1 reply by Stéphane Parent
May 10, 2016 4:26 PM
Stéphane Parent
...
You are correct, Patrick. Schedule and cost performance, or actual results, do not cause a rebaseline.
The problem here is in planning additional effort and costs. You could technically add activities to your schedule, and the additional assignments would be added to your budget, without baselining either of them.
The bottom line is that your baseline is always against planned values, not actual values.
If you do that, you will still be measuring your performance against your last baselines, the ones without your additions.
Saving Changes...
Patrick DiceyManager, Customer Project Management| CentralSquare TechnologiesOrlando, Fl, United States
It's interesting how a simple topic such as action items can ripple throughout all the PM processes. Saving Changes...
