Section 7: Weekly Tracking - Oakland County, Michigan

Oakland County Department of Information Technology Section 7 – Weekly Tracking

Rev: 02/28/2018 Page 7.1

Section 7: Weekly Tracking

Overview Immediately following the weekly Timesheet posting cycle, Resource Managers and Project Managers must prepare project plans for the coming week. Team Members will create new Timesheets requiring the most current task information possible for tracking purposes. Project Managers will update detailed project plans with the current status in Clarity for reporting purposes. Open Workbench, through views, will provide the necessary steps to assist Resource Managers and Project Managers with this process.

Weekly Tracking and Clarity

Weekly tracking for detailed project plans begins in Clarity, and is later reviewed and refined using Open Workbench. To begin weekly tracking in Clarity

1. Launch the Clarity application. 2. From the Overview: General page, under My Projects, click the appropriate project name link.

Or

1. Under Portfolio Management, click the Projects link. 2. Enter the Project Name or ID in the Project Filter section of the Projects page, click the Filter button. 3. Click the Project Name link.

Review Project Dashboard

The Project Dashboard displays several portlets that contain project information. Project Dashboard data is drawn from the information entered for tasks and resource assignments, as well as the data submitted on weekly timesheets. Several of the portlets display alerts, in the form of flags:

Green On-Track.

Yellow Warning.

Red Critical.

As part of the Weekly Tracking process, the Project Manager should review the information on the Project Dashboard to assess the overall status of the project. Particular attention should be paid to yellow and red flags. Project information cannot be modified on the Project Dashboard. Refer to the Weekly Tracking and Open Workbench Views section for more information on modifying project data.

The Project Dashboard is composed of the following portlets:

General

Basic information about the project is displayed; Project Name, Project ID, Start Date, and Finish Date. The Baseline Finish Date shown is the project’s original Baseline Finish Date. If the project is rebaselined with a different finish date, the Baseline Finish Date field does not change. The new Baseline Finish Date is displayed in the Planned Finish Date on the Schedule Variance – Includes Preliminary and Schedule Variance – Non-Preliminary Only portlets.

Section 7 – Weekly Tracking Oakland County Department of Information Technology

Page 7.2 Rev: 02/28/2018

Assignment Compared to Baseline Graph

This graph shows the Baseline and Total Usage on the project broken out by week. The Baseline is the amount of work that was approved when the project was presented to the IT Steering Committee. The Total Usage is either Actual work completed for dates in the past, or Estimate to Complete for the current week and future weeks. Ideally, Baseline and Total Usage should be fairly close together. If Total Usage is higher than Baseline, the resources on the project have worked more than what was committed (past dates) or are scheduled to work more than what was committed (future dates). If Total Usage is lower than Baseline the resources have worked, or are scheduled to work, less than what was committed. This could indicate that ETC on the project is high, or it could indicate that the project end date is at risk for slipping.

Team Utilization

The project’s Total Usage per resource for all tasks is displayed. The Team Utilization portlet provides various links to obtain detailed Resource assignment and utilization information.

Allocation Variance

The project’s Allocation Variance information is displayed; Master Plan Allocation, Total Usage and Allocation Variance. The Total Usage displays the project’s total usage during the current Master Plan period. This value will be different than the project’s overall total usage if the project spans more than one Master Plan (i.e. the project is a carryover).

Usage Variance – Non-Preliminary Only

The project’s labor effort, without preliminary estimates, is displayed; Baseline, Total Effort, Variance Hours and Variance Percent. The Variance Percent flag is based on the following conditions:

Green 0 – 4.9% negative or 0 – 9.9% positive variance.

Yellow 5 – 9.9% negative or 10 – 19.9% positive variance.

Red more than 10% negative or more than 20% positive variance.

Schedule Variance – Non-Preliminary Only

The project’s schedule, without preliminary estimates, is displayed; Planned Finish Date, Finish Date and End Days Variance. The Planned Finish Date shows the project’s current Baseline Finish Date. If the project was rebaselined due to a project renegotiation the Planned Finish Date in this portlet may be different from the Baseline Finish Date field in the General portlet. The Finish Date shows the scheduled project completion date, as determined by autoschedule. The End Days Variance calculates the difference between the Planned Finish Date and the Finish Date. The End Variance Days flag is based on the following conditions:

Green 0 - 14 days early or late.

Yellow 15 - 29 days early or late.

Red 30+ days early or late.


Rev: 02/28/2018 Page 7.3

Scope Budget – Non-Preliminary Only

The project’s Scope Budget information, without preliminary estimates, is displayed; Scope Baseline, Scope Actuals, Scope ETC, Coded Total Usage, Uncoded Total Usage, Scope Total Usage, Scope Variance Hours.

According to IT Steering Committee standards, newly added tasks to detail project plans (i.e., tasks with no Baseline) must have a value in the task’s Category field. Any Unbaselined Tasks without a Category are assumed to be Scope Change tasks. The Total Usage of tasks with no Category is displayed in the Uncoded Total Usage column and flagged with in yellow. Refer to the Add Tasks section for more information regarding viewing and updating Unbaselined Tasks with no Category.

IT Steering Committee standards also indicate a project must be renegotiated if the Scope Change Management Budget is exceeded. Any Variance, whether negative or positive, is displayed in the Scope Budget Variance field. If the variance is negative this field is flagged in red. Refer to Section 4: Change Request Process for more information about managing the project’s Scope Change Management Budget.

In general, only detailed project plans have a Scope Change Management Budget. Budgets and Team Plans typically do not manage scope. If a project does not have a Scope Change Management Budget this portlet will display a message stating there are no items to display.

Contingency – Non-Preliminary Only

The project’s Contingency information, without preliminary estimates, is displayed; Contingency Baseline, Contingency ETC and Contingency Used. Most detailed project plans have several Contingency tasks, typically one task for each phase of the project. The Contingency Used calculates the difference between the Contingency Baseline, and the Contingency ETC. Refer to the Contingency Status sections of this document for more information about managing the project’s Contingency.

In general, only detailed project plans have a Contingency. Budgets and Team Plans typically do not. If a project does not have Contingency this portlet will display a message stating there are no items to display.

Usage Variance – Includes Preliminary

The project’s labor effort, including preliminary tasks, is displayed; Baseline, Total Effort, Variance Hours and Variance Percent. The Variance Percent flag is based on the following conditions:

Green 0 – 4.9% negative or 0 – 9.9% positive variance.

Yellow 5 – 9.9% negative or 10 – 19.9% positive variance.

Red more than 10% negative or more than 20% positive variance.

Schedule Variance – Includes Preliminary

The project’s schedule, including preliminary tasks, is displayed; Planned Finish Date, Finish Date and End Days Variance. The Planned Finish Date shows the project’s current Baseline Finish Date. If the project was


Page 7.4 Rev: 02/28/2018

rebaselined due to a project renegotiation the Planned Finish Date in this portlet may be different from the Baseline Finish Date field in the General portlet. The Finish Date shows the scheduled project completion date, as determined by autoschedule. The End Days Variance calculates the difference between the Planned Finish Date and the Finish Date. The End Variance Days flag is based on the following conditions:

Green 0 - 14 days early or late.

Yellow 15 - 29 days early or late.

Red 30+ days early or late.

Baseline

Project baseline information is shown on the project’s Baseline tab. Project Managers and Supervisors can use this information to compare multiple baseline iterations to previous versions, and to the initial baseline, in order to identify and analyze changes in the project usage and schedule.

Update Project Status

The Project Status field allows the Project Manager to provide a status of the project which may not be known by reviewing Project Dashboards, reports, or views. An example might be communicating a variance on a project to your Division Manager. The frequency of how often a status should be entered is at the discretion of your manager. However, a project status is required whenever a project meets certain variance criteria.

S The Project Manager must enter a Project Status whenever the project reaches ● -10% Usage Variance, or ● +20% Usage Variance, or ● -30 days Finish Date Variance, or ● 100 hours of Unbaselined Actuals

1. Click the Properties tab. 2. From the Project Properties: Main – General page, under Properties, click the Project Status link. 3. Click the New button. 4. Enter all required fields. 5. Click the Save and Return button.

Field Name (Characters) Usage Value

Name Required Enter the Project Status Name.

ID Required Leave as default – autonumber.


Rev: 02/28/2018 Page 7.5

Field Name (Characters) Usage Value

Variance Explanation? Optional Check the appropriate value: Checked – Status is a variance explanation. Unchecked – Status is a general comment about the status of the project.

Status Date Optional Defaults to today’s date.

Status Optional Enter the Project Status. Weekly Tracking and Open Workbench Views

The Open Workbench View Library is broken down into a number of folders, based on the status of the Project Planning and Control process. The Weekly Tracking folder contains all the necessary views to perform Weekly Tracking.

Add Tasks

This view displays all tasks in the plan and should be used when adding tasks or to review the plan in detail.

Review the project to determine where to insert added tasks. Added tasks should be either Scope or Issue related. When adding tasks to a project plan resulting from Scope Change, the Project Manager must obtain Scope Change approval, and decrement the Scope Change task in the Project Management (PM) Phase by the total amount of ETC. If the Scope Change task remaining ETC is not enough to cover the added tasks, the Project Manager must renegotiate the project for additional Scope hours. Refer to Section 4: Change Request Process, for more information.

S New tasks that result from an approved scope increase must be added to the project plan at the appropriate point(s) in the project. These tasks must be flagged by entering a “C” in the first position of the task Category field. The Scope Change Management task should be decremented by the total ETC amount of the added Scope Change task.

S Time spent for Scope Change planning, analyzing, documenting and obtaining approval should be tracked directly to the Scope Change Management task.

S Unused ETC in an added Scope Change task must be added back into the PM Phase Scope Management task ETC once the added task has been completed.


Page 7.6 Rev: 02/28/2018

Issues may be tracked to the Issue Management task in the PM Phase or the Project Manager may create a separate task for more specific issue tracking. When adding tasks to a project plan resulting from an issue, the Issue Management task in the PM Phase must be decremented by the total amount of ETC. If the Issue task remaining ETC is not enough to cover the added tasks, the Project Manager can use Contingency hours. If the Contingency remaining ETC is not enough to cover the added tasks, then the Project Manager must renegotiate the project.

S New tasks that result from an issue must be added to the project plan at the appropriate point(s) in the project. These tasks must be flagged by entering an “I” in the first position of the task Category field. The Issue Management task ETC should be decremented by the total ETC amount of the added Issue task.

S Time spent for issue identification, monitoring, tracking and resolution should be tracked directly to the Issue Management task.

S Unused ETC in an added Issue related task must be added back into the PM Phase Issue Management task ETC once the added task is complete.

Once tasks have been added and the ETC adjusted, the project should be Autoscheduled using the first day of the current work week.

Note: Do not add tasks while in a Team Group Plan. If a task is accidentally added in a Team Group Plan, the task will be added to the wrong project plan. Instead, open the individual project plan to add tasks. Review Weekly Actuals

This view displays the Actuals entered for the prior week time reporting period. The date shown in the Time Scale is the first day of the time reporting period (always starts with a Saturday).

Review Actuals entered for each Team Member making sure that hours were tracked as the Project Manager had intended. If Actuals have been tracked incorrectly, notify the Team Member to adjust the Timesheet. Complete Tasks/Revise End Date

This view will display all started tasks in a project.


Rev: 02/28/2018 .7

Review started tasks to determine tasks that can be completed. When completing tasks, change the Estimated to Complete (ETC) to zero, the end date to the actual date the task was completed, and the status to “Completed”.

Note: Task end dates cannot be changed prior to the Actuals through date. ETC Equal to Zero

This view displays all tasks that have ETC equal to zero.

Review tasks to determine those that should be completed or ETC that should be changed. Refer to Complete Tasks/Revise End Date, for completing tasks with zero ETC. When adding ETC to a task, remember to decrement the Contingency task.

S When the remaining ETC on a task is determined to be too low, the ETC should be increased. The amount of the increased ETC should be subtracted from the Contingency task ETC within that phase. For example, if the original ETC for a programming task needs to be increased by 7 hours, the Contingency task ETC in the programming phase is decremented by 7 hours.

Past ETC Not Equal to Zero

This view displays all ETC in the past for assigned Team Members.

Review the time scale total for the week. If the total is not zero, scroll through the project to identify specific tasks with an ETC greater than zero in the time scale. Review the Actual Thru Date to determine if the Team Member posted time through the current time period.

Listed below are some of the reasons why ETC in the past could exist:

• Locked tasks in the past that have not been started. Project Manager should unlock tasks and Autoschedule or change the task start date to a future date when the task will actually start.

• Autoschedule was not performed.

• ETC does not more forward until Actuals are posted for the resource.

• Open Workbench does not move ETC forward on generic roles. Project Manager must adjust ETC manually.

Check Fixed Locked

This view displays all Tasks and Milestones that have not been completed where the duration is fixed and the end date is locked. Keeping accurate track of the fixed and locked dates is important to ensure the schedule is being met.

Review all Tasks and Milestones with fixed durations and locked dates. If the duration or date is no longer valid, then change the end date to reflect the new schedule. If the overall schedule is affected, then a project renegotiation may be required.


Page 7.8 Rev: 02/28/2018

Milestones Status Tracking

This view displays all Milestones in a project. Keeping accurate track of the Milestones is important to ensure deliverables are being met on time. Milestones serve as predecessors or successors to other tasks, therefore any slippage may impact the rest of the schedule.

Review all Milestones Planned End Dates. If the Milestone should be completed, change the end date to the actual date the Milestone was completed and change the status to “Completed”. Milestone end dates should always be in the future, change Milestone end dates that are in the past. Verify future Milestone end dates to ensure the delivery is on track. Review Milestones Planned End Dates that are locked and adjust dates according to the revised schedule. Contingency Status – All Phases

These views display tasks for all phases of the project and less than zero variance.

Review Contingency tasks (Task ID = XX9997, XX represents the Phase ID) and the Contingency task remaining ETC for each phase. If a Contingency task requires additional ETC, increase the task ETC and decrement the Contingency task for the phase. Decrement the Contingency task by the total amount of the increased ETC. If the Contingency ETC is not enough to cover the increased ETC, then the Project Manager may either move Contingency ETC from another approved phase or renegotiate the project. If no Contingency ETC remains for other phases, the Project Manager must renegotiate the project. Dependency Violations

This view displays tasks with dependency violations. The dependency violations are highlighted in bright green in the primary task name field of the view. Review all highlighted tasks. Review the task and the related tasks start and end dates to determine which of the related tasks may be causing the violation. The most common occurrence is where a successor task or milestone has started prior to its predecessor. If the highlighted task is not started, the Project Manager may consider realigning the dependencies.

Note: Not all dependency violations may be resolved, but the Project Manager should attempt to resolve tasks that have not yet been started. Charge Code Review

This view displays Charge Codes that are associated at an activity level with the project plan. This view should be used for Team Group and individual Team plans only.

Scroll through the project ensuring that all activities have been assigned a correct charge code. All Non-Project, Team Management, Customer Support, System Maintenance and Planned Maintenance and Upgrade plans must have a Charge Code assigned at the activity and task level. If a Charge Code is incorrect or missing, the Project Manager can add/change the Charge Code. Activities and tasks with missing Charge Codes will appear on the PMO Weekly PM System Reporting email.

1. From this view, under Task Charge Code, click the drop down menu to select a Charge Code for a task.

2. Click the correct Charge Code.


Rev: 02/28/2018 Page 7.9

3. From the menu bar, click File…Save.

Note: If the Charge Code is changed for a task with Actuals, the Project Manager should notify PMO. Timesheets will need to be adjusted to prevent billing errors. Charge Code Review – Detail Plan

This view displays Charge Codes that are associated at the project level. This view should be used for detail project plans only.

Review Charge Code shown at the top of this view to determine if correct. If an incorrect Charge Code has been entered, the Project Manager must notify and work with the Project Management Office (PMO) to correct any Timesheets that may have already posted or been billed.

Variance Explanation

This view displays Variance Explanations that are associated at an activity level within a Team Group or individual Team project plan.

For projects that have been rebaselined, there is a discrepancy between the way Open Workbench displays baseline information rolled up at the activity, phase, and project level and the way Oakland County Information Technology interprets the rebaselined information. It is recommended that the Usage Analysis – Activity Level report be used to monitor activity-level variance. However, variance explanations must be entered in Open Workbench.

G It is recommended that the Usage Analysis – Activity Level report be used to monitor variance at the project, phase, and activity level. The Clarity Project Dashboard can also be used to monitor project-level variance.

Run the Usage Analysis – Activity Level report. Scroll through the report, reviewing activities. In Open Workbench, enter a Variance Explanation for all activities with a +/- 20% variance.

1. From this view, right click on the activity. 2. Click Notes. 3. Enter a Variance Explanation. 4. Click the Add button. 5. Click the OK button. 6. A Variance Explanation will be displayed under the Analysis column. 7. From the menu bar, click File…Save.

S Variance explanations are required at the Activity level for Customer Support, System Maintenance, and Planned Maintenance and Upgrade plan files if the variance percentage is +/- 20%.

Variance Explanation – Detail Plan


Page 7.10 Rev: 02/28/2018

This view displays the Variance Explanation that is associated at a project level. This view should be used for detail project plans only.

For projects that have been rebaselined, there is a discrepancy between the way Open Workbench displays baseline information rolled up at the activity, phase, and project level and the way Oakland County Information Technology interprets the rebaselined information. It is recommended that the portlets on the Clarity Project Dashboard be used to monitor project-level variance. However, variance explanations must be entered in Open Workbench.

G It is recommended that the Usage Analysis – Activity Level report be used to monitor variance at the project, phase, and activity level. The Clarity Project Dashboard can also be used to monitor project-level variance.

Review the Variance Percent. If the Variance Percent is +/- 20% variance, enter a Variance Explanation in the project’s notes.

1. From this view, right click on the project name. 2. Click Notes. 3. Enter a Variance Explanation. 4. Click the Add button. 5. Click the OK button. 6. A Variance Explanation will be displayed under the Analysis column. 7. From the menu bar, click File…Save.

S Variance Explanations are required at the Project level, in the project’s notes, for detail plan files if the overall Project Variance percentage is +/- 20%.

Review Weekly Actuals/Notes

This view shows Team Member weekly Actuals and the task notes that have been added by the Resource Manager or Project Manager.

Review the note text for specific tasks and the Team Member Actuals in the time scale. Remove and update notes where applicable.

Monitoring Project Variance Project Managers are responsible for monitoring Project Variance on a weekly basis when performing weekly tracking. There are many different types of variance the Project Manager must pay attention to. Usage Variance occurs when Total Usage (Actual hours worked plus Estimate To Complete) is significantly greater or lower than the Baseline Usage. Date Variance occurs when the Scheduled Finish Date is considerably earlier or later than the Baseline Finish Date. Unapproved Activity is another type of Project


Rev: 02/28/2018 Page 7.11

Variance. Unapproved Activity happens when work is done on unbaselined tasks, such a prior to the project being approved and baselined, or when an approved project’s Scope Change Management budget is exceeded. Project Variance can be caused by a number of factors:

• Low Estimates are a frequent cause of Usage Variance. Once the Contingency budget for a project phase is exceeded, the project may be in negative usage variance.

• High Estimates may also be a cause for Usage Variance. Occasionally task estimates in a project that are consistently high may result in positive usage variance.

• Not following process may also be a cause for Usage Variance. If Scope Change Management and/or Contingency budget tasks are decremented correctly, the negative variance caused by the extra work will be balanced out by the positive variance in these budget tasks. If these processes are not followed consistently, and the budgets are not decremented, the project will appear to be in negative usage variance.

• Overcommitting Resources can be a cause of Finish Date Variance. Despite the best planning efforts, resources may not always be available to work on the project as often as was anticipated. This causes tasks to take longer to complete, and can eventually cause the entire project to be late.

• Unexpected Delays can contribute to Finish Date Variance. Most projects involve external resources, such as customers and vendors, whose actions are beyond the Project Manager’s immediate control. If these resources fail to meet their commitments and deadlines the IT project team may not be able to continue their work as scheduled.

Project Variance is most often caused by a combination of these and other factors. PMO generates Project Variance reports weekly. PMO will contact any Project Manager whose project exceeds -10% usage variance, +20% usage variance, -30 days finish date variance, or 100 hours of unbaselined usage. The Project Manager and his or her Supervisor will be required to present a Variance Explanation, along with a proposal to correct the variance, to the IT Steering Committee at the next scheduled weekly meeting. The IT Steering Committee may also recommend a course of action to address the variance. This could include renegotiating the project’s end date, or even the entire project; ongoing monitoring of the variance; increasing the project’s Scope or Contingency budgets; putting the project on hold; or perhaps even canceling the remainder of the project. The IT Steering Committee may also require the Project Manager to present updates of the project’s status at subsequent weekly meetings.

S Once a project exceeds -10% usage variance, +20% usage variance, -30 days finish date variance, or 100 hours of unbaselined activity, PMO will initiate a Variance Explanation Status Report. The Project Manager and Supervisor must present a variance explanation to the IT Steering Committee at the next weekly Steering Committee meeting. The IT Steering Committee will recommend a course of action to address the variance, and for subsequent follow-up on the project’s status.

Section 7: Weekly Tracking - Oakland County, Michigan

Documents

Transcript of Section 7: Weekly Tracking - Oakland County, Michigan