When you finish creating a project plan and dependency relationships, you are ready to schedule tasks and the resources that work on tasks. If your project is large, scheduling can be a complex process that balances task relationships, resource availability, and task duration.
Because scheduling is an iterative process, it usually takes several steps to balance resources working on a project. This means that you may need to make several adjustments to your project plans. Adjustments can include changing resource availability, adjusting dependency links, and adding tasks.
To ease the burden of scheduling projects, Open Workbench uses an automated scheduling process called Autoschedule.
This section contains the following topics:
How to Develop Project Schedules
How to Schedule Projects using Open Workbench
Following are some steps that you might use to develop a realistic schedule:
There are several scheduling techniques you can use to schedule your projects using Open Workbench. The scheduling process involves the following steps:
You can recalculate task duration so that Open Workbench computes the shortest possible task duration. To recalculate task duration, select one or more tasks from the current view, and select Tools, Recalculate.
To eliminate resource over commitment and to maximize resource use, Open Workbench recalculates task duration according to the ETC, total resource availability, and maximum percentage load. The following mathematical calculation is used for recalculating task duration:
Duration = actuals + ETC/(resource availability per day) x (max % availability per day)
The recalculation process also maximizes resource use to shorten task duration whenever possible. If a task is inherently over committed, recalculating task duration can extend its duration to eliminate any inherent resource over commitment for that period. The exception to this is when the task is fixed.
When you assign multiple resources to a task and you recalculate the task's duration, Open Workbench computes the duration for each resource separately and selects the longest duration to determine the total task duration. All incomplete tasks in the selected range are adjusted, except for fixed tasks. If you recorded resource actual usage on the task, the ETC is modified.
Tasks with a Contour loading pattern are recalculated as Uniform. The recalculation process also replaces patterns created by Autoschedule, and computes duration based on total availability per task. Locked or completed tasks are not impacted by the recalculation process. Instead, if the task has an ETC, the incomplete portion of the task is modified.
Example 1
Resource availability is 8 hours per day and the maximum percentage is 50% (the resource can work on this task 4 hours per day). If usage is 12 days, when you recalculate the task duration, the task's duration computes to 24 business days.
Example 2
Resource availability is 4 hours per day and the maximum percentage is 50% (the resource can work on this task 2 hours per day). If usage is 12 days, when you recalculate the task duration, the task's duration computes to 48 days.
A baseline is a snapshot of the original project plan that you preserve for later comparison with the current plan. You can baseline to evaluate a project and compare it to an approved plan. Baselining preserves a version of the plan that does not change as work on the project progresses, unless you baseline the project again.
You can baseline a task, a selected range of tasks, all tasks in a view, or the entire project. When you create a baseline, you preserve information such as start dates, finish dates, and usage from that moment in time. You can then compare the current plan with the baseline plan to determine if the project is proceeding as expected.
The appropriate time for you to baseline a task or resource assignment data is after management approves the project plan and before the task starts and actuals are tracked. This gives you a reference against which to measure the project progress. If the plan goes through several review cycles, and management approves a new basis for measurement, you can rebaseline the task so that you can compare the revisions with the original plan.
Open Workbench supports multiple baselines so you can create new baselines as the project progresses.
Open Workbench factors in baseline information in many calculations performed in earned value analysis.
Earned Value Analysis (EVA) is a statistical operation that compares the project's present actuals against what was planned. For example, it may compare the length of time a task would take, according to a baseline budget plan, to the actual length of time it took. EVA is also called Performance Measurement.
Open Workbench includes fields containing the fundamental calculations used for earned value analysis. These fields are available as discrete items for reporting purposes and you can add them to any view. These fields are used primarily as variables by other calculated fields to produce variance values.
Earned value calculates the following values for every scheduled activity:
The budgeted amount to be spent on the project in a given period of time.
The total direct and indirect cost incurred in performing work during a given period of time.
The percentage of the total budget equal to the percentage of the actual work performed.
These values are used together to determine if work is being performed as planned. The most frequently employed measures are:
Use the EVA fields to track work performance to account for cost and schedule variances. For example, Open Workbench computes BCWS using the following formula:
BCWS = (cumulative baseline usage from the start date through the Project as-of date) x (the resource billing rate)
Note: You must baseline your project to attain date or EAC variances.
Use the Multiple Baselines dialog box to set baselines and to re-baseline your project. This dialog box lists the baselines that you have already set on the project. When you set a new baseline, its default name is Baseline1 and it is marked as the current baseline. If the project already has a baseline named Baseline1, then when you set a new baseline its name is Baseline2. You can edit the name after you capture the baseline.
You must select all levels of the WBS to re-baseline your project. When you re-baseline tasks that have changed—such as changes to a resource's ETC—the data is not rolled up to the summary task level. Data, however, is rolled down to a phase's tasks when you re-baseline at the summary task level.
To set a baseline
The Multiple Baselines dialog box opens.
A new baseline is set and is displayed in the list.
The Baseline dialog box closes.
You can display one baseline in a view at a time. To view baseline information, you must first include the fields that display baseline data in one of your views. You can display the current baseline in a spreadsheet view, such as the Gantt Chart view, against the current status of the project. Special baseline markers on Gantt bars indicate the baseline information to differentiate the baseline information from the current schedule.
To include the fields that display baseline data in a view
To display a baseline
The Gantt dialog box appears.
The baseline markers appear next to the Gantt bars on the Gantt chart.
Use the Multiple Baselines dialog box to edit a baseline's name, description, and code, and to set a baseline as the current baseline.
To edit a baseline
The Multiple Baselines dialog box opens.
Note: You can select one baseline as the current version.
The Baseline dialog box closes.
Use the Set Baseline dialog box to re-baseline your project. When you rebaseline your project, the current baseline is replaced with the new baseline data.
Note: When you choose to rebaseline the view or selected tasks, the project baseline values are not updated.
You must select all levels of the WBS to rebaseline your project, view, or selected tasks. When you rebaseline tasks that have changed—such as changes to a resource's ETC—the data is not rolled up to the summary task level. Data, however, is rolled down to a phase's tasks when you re-baseline at the summary task level.
When this is the case, you are asked to .
To rebaseline a project
The Baseline dialog box opens.
The current baseline is replaced with the new baseline data.
When you set the baseline for a master project, you also set it for the project's subprojects. The master project's baseline data is an aggregation of its own baseline data and its subprojects. It is dynamically aggregated at the time you set the baseline. The master project's resource baseline data is an aggregation of the team baseline data.
When you open a master project that you have not baselined, but one of the subprojects has been baselined, the current baseline for that subproject is displayed in views. For example, if you have a master project with two subprojects, Subproject1 and Subproject2, and only Subproject1 has a current baseline, Baseline1, and you rename that baseline, and you baseline a selected task in Subproject2, then Subproject1's baseline is deleted and is replaced with Subproject2's baseline. Subproject2's baseline is marked as the current baseline.
If you are using Open Workbench with CA Clarity PPM and you create multiple baselines for a master project, a baseline (Baseline1) is created for the master project and its subprojects. When you save the master project back to CA Clarity PPM, the baseline data for the master includes the values from the subprojects. For example, if you have a master project that has a task with 5 hours of ETC, and its two subprojects have a task with 10 hours ETC each, then when you save the project back to CA Clarity PPM, the master project baseline usage is 25 hours.
If you open a master project that you have baselined, and then add a new subproject, the existing subproject's current baseline is saved. If you baseline the master project, the subproject's baseline is replaced by the new baseline. If the master project's subprojects have more then one baseline, the baseline that is marked as the current baseline displays in views.
Note: If you are using Open Workbench with CA Clarity PPM, to keep master project baselines in sync with subproject baselines, do not change which baselines are marked current without first changing them in CA Clarity PPM. When you open a CA Clarity PPM project in Open Workbench, all baseline data defined in CA Clarity PPM is loaded into Open Workbench.
When you maintain multiple baseline versions, the current version is the version from which earned value analysis (EVA) is measured. You can change the current version any time.
If you are using Open Workbench with CA Clarity PPM, you can set multiple baselines and save the project back to CA Clarity PPM. By default, when you create a new baseline, it is selected as the current version. You can choose to select another baseline to be the current version.
When you create a new baseline, the name and code of the new baseline by default is baselineN, where N is an incremental number starting at 1. Double-click the cell to change the value.
To set multiple baselines
The Multiple Baselines dialog box opens.
A new baseline is added to the grid and is selected as the current baseline version.
Defines the code for the baseline.
Defines the name of the baseline.
Defines the description of the baseline.
The Multiple Baselines dialog box closes.
You can create a baseline with which to analyze the impact of the additional work. When you select only a few of the project tasks and baseline, the baseline values are updated for those tasks. The summary level baseline information remains the same until you update the baseline for the selected summary task, or the entire project. Use the summary level baseline to analyze the changes that have occurred at that level, even though they do not show at the task level.
Use the Set Baseline dialog box to clear baseline values or to rebaseline. Clearing baseline values replaces existing baseline data that has been set for all of the tasks in a project, all of the tasks in the active view, or a selection of tasks.
If you are using Open Workbench with CA Clarity PPM, save the project to CA Clarity PPM after you clear the current baseline values.
To delete entire baselines, use the Multiple Baselines dialog box.
To clear baseline values
The Baseline dialog box opens.
An Open Workbench dialog box appears warning you that clearing the baseline replaces your existing baseline data.
The baseline values are cleared.
Use the Multiple Baselines dialog box to delete a baseline or to edit your baseline. If you want to delete a previous baseline but that baseline is marked as current, clear the baseline's Current field before deleting. You can only delete the current baseline if it is the only baseline listed.
To delete a baseline
The Multiple Baselines dialog box opens.
The baseline is deleted. The baseline row no longer displays in the grid.
Autoschedule is an automated way for you to create project schedules. Autoschedule schedules tasks based on an internal set of rules that are set by the system. Each task is scheduled:
Before scheduling, Autoschedule automatically calculates the project's critical path. Autoschedule does the following in this order:
Autoschedule uses the following factors to determine the order in which subproject tasks are scheduled, and are considered in this order:
If two or more tasks have equaling factors, the next factor in the queue is taken into account. For example, if you have two tasks, both with no defined scheduling constraints and a priority of 5, and the first task's float is less than the second task's, the first task is scheduled before the second.
By default, Autoschedule operates on the entire project, but does not change tasks that:
Note: You can override the task lock.
Autoschedule performs three passes of the project to create a schedule that satisfies all dependencies and does not overallocate selected resources. Each includes a forward pass and a backward pass. To develop a schedule, the following three passes are performed whether you schedule from the project start or finish date:
Important! You can set dependencies, constraints, and resource availability so that it is impossible for Autoschedule to produce a schedule free of dependency violations or resource over allocations.
Use the Autoschedule dialog box to specify scheduling criteria and to begin scheduling tasks using Autoschedule. You can autoschedule an entire project or only tasks that occur between ranges of dates.
To define Autoschedule parameters and schedule your project
The Autoschedule dialog box opens.
Defines the date from which to begin scheduling tasks. If you are scheduling from the finish date, enter the date on or before which you want to begin scheduling tasks.
Defines the date before which you want tasks to be excluded.
Example: If you enter 4/3/2008 as the Ignore Tasks Starting Before date, and you have a task that starts on 3/31/2008, this task will be excluded from the schedule.
Defines the date after which you want tasks to be excluded.
Example: If you enter 4/3/2008 as the Ignore Tasks Starting After date, and you have a task that starts on 4/10/2008, this task will be excluded from the schedule.
Specifies whether you want Autoschedule to consider resource availability when scheduling the project.
Default: Selected
Note: If you clear this check box, Autoschedule treats resources as if they have unlimited availability. Each task is scheduled against the resources total availability, not against the resources remaining availability which takes other task assignments into consideration. This results in the shortest possible schedule, but it may also cause resources to be overcommitted.
Specifies whether you want Autoschedule to perform a backwards schedule from a defined deadline date.
Default: Cleared
Note: If you choose to schedule from the finish date, the Start Date field toggles to the Finish Date field.
Specifies whether you want Autoschedule to honor any constraints or dependencies you have on tasks with a status of "Started".
Default: Cleared
Note: If you choose to honor constraints on started tasks, you run the risk of overallocating resources or violating task dependencies.
Specifies whether you want Autoschedule to move the assignment ETC within the scheduling Start Date and the task's Finish Date.
Default: Cleared
Specifies whether you want Autoschedule to start successor tasks with zero lag the day after the predecessor task finishes. When cleared, successor tasks start the same day as the predecessor task finishes as long as the resource has availability left.
Default: Cleared
Note: This applies to variable-duration tasks only.
The project or selected tasks are scheduled.
You can autoschedule a group of subprojects from the master project to show the best fit of all tasks in all projects.
Best Practices: Before autoscheduling your master project, create a project start milestone for each subproject and link it to the first task in the master project. You can then lock or define a Start No Earlier Than date constraint to the milestone to assist with the individual project time frame constraints.
The master project's resource list contains the names of the resources assigned work on the projects contained in the master projects, the subprojects.
When you schedule a project from its start date, Autoschedule attempts to schedule all project tasks to start as early as possible. When you run Autoschedule using a project's start date, it calculates the early start and early finish, moves the early start forward, checks for fixed loading pattern assignments, and adjusts the early start or early finish to make sure that fixed assignments are within the date range of the project.
When you autoschedule your project, the task start dates change to the date you enter or a later date, except in the following cases:
To schedule your project from a start date
The Autoschedule dialog box opens.
The project or selected tasks are scheduled.
You can autoschedule projects from a finish date to help you find out on which date your project needs to start in order to meet a required finish date. When you choose to schedule your project based on its finish date, Autoschedule performs three traversals of the project. In the second and third traversals it goes over the tasks backward first and enforces finish constraints over start constraints so that the project is scheduled to start as late as possible.
When you run Autoschedule using a project's finish date, it does the following:
To autoschedule your project from a finish date
The Autoschedule dialog box opens.
The Start Date field toggles to the Finish Date field. The current project finish date displays in the Finish Date field.
The project or selected tasks are scheduled from the finish date.
The Task Priority controls the order in which tasks are scheduled during autoschedule, subject to dependencies and task and resources constraints. Autoschedule, therefore, schedules tasks with higher priority ahead of tasks with lower priority. Use the General tab on the Task Properties dialog box to define a task's priority or priority inheritance. If you do not specify a task's priority, Autoschedule uses the priority of its parent task, or the next highest WBS level. If no priority is defined, Autoschedule uses the default value (10).
Autoschedule schedules task priority as follows:
For example, if the task has a priority of 0 through 9, it is given the highest priority during scheduling. If the task has a priority of 11 through 36, it is given the lowest priority during scheduling.
In the case of dependencies, Autoschedule assumes that a predecessor task has a priority at least equal to its successor. In some cases, dependency relationships override individual task priority during the scheduling process.
You can override the lock on tasks while autoscheduling. For example, if you have a task that is locked between February 25, 2008 and April 4, 2008, Autoschedule distributes the assignment's ETC to the task between the two dates. If you do not override the lock and Autoschedule changes the task's end date to April 25, 2008, the assignment's ETC remains between February 25, 2008 and April 4, 2008. However, if you choose not to override the lock, the assignment's ETC is distributed between February 25, 2008 and April 25, 2008, per the assignment's loading pattern.
When scheduling locked tasks using this option, Autoschedule adheres to the following rules:
To override the task lock during Autoschedule
The Autoschedule dialog box opens.
The project or selected tasks are scheduled and the lock on tasks is overridden.
Use the Scheduling tab on the Project Properties dialog box to define the project's scheduling attributes, such as the project's start and finish dates. This data is used when scheduling the project. You should schedule all project tasks to begin and end during the project period.
Note: If you use Autoschedule, these dates may change according to resource assignments, task dependencies, and constraints.
To manually schedule a project
The Description tab on the Project Properties dialog box opens.
The scheduling properties display.
Defines the project's start date.
Default: The current system date.
Specifies whether or not you want to impose a start date for the project.
Note: You must select this field if you later autoschedule your project from its start date. When selected, Autoschedule cannot change the project's start date to accommodate any changes it makes to the start and end dates of the project's tasks, no matter when the first task starts.
Defines the anticipated project completion date. The project's finish date must equal or be beyond the finish date of the last task. This date is used as the finish date for the last task in the CPM Network.
Specifies whether or not you want to impose a finish date for the project.
Note: You must select this field if you later autoschedule your project from its finish date. When selected, Autoschedule cannot change the project's end date to accommodate any changes it makes to the start and end dates of the project's tasks, no matter when the last task finishes.
Defines the date that is used as a reference point when performing Earned Value Analysis (EVA) calculations. If you do not enter an as-of date, zero (0) displays in earned value fields such as Actual Cost of Work Performed (ACWP) and Budgeted Cost of Work Performed (BCWP).
Defines the order in which subprojects are scheduled within a master project. The priority amount you enter here is used as the default priority for summary tasks; any lower-level WBS tasks that have been marked as inheriting the priority of its parent assumes this priority amount.
Default: 10
Values: 0 through 36 (A lower number indicates a higher priority)
Example: If the project has a priority of 0 through 9, its tasks are given the highest priority during scheduling. If the project has a priority of 11 through 36, its tasks are given the lowest priority during scheduling.
Defines on which dates to base the critical path during CPM calculations.
Default: Current
Values:
Specifies whether you want CPM to calculate the project's critical path separately for each subnet. When cleared, one critical path is calculated for the entire project.
Default: Cleared
The Project Properties dialog box closes.
Subnets are a set of tasks in a project that have dependencies among themselves. During Autoschedule, you can choose to calculate and display separate critical paths for each subnet and for each task that does not have dependencies. Otherwise, only one critical path—the longest path—is calculated for the project. Use the Subnets (All Projects) check box on the Scheduling tab to specify whether you want CPM to calculate the project's critical path separately for each subnet.
There are several key benefits to scheduling subnets:
To set up your project to calculate separate critical paths
The General tab on the Project Properties dialog box appears.
A list of the project's scheduling properties display.
Your project is set up to calculate separate critical paths.
Separate critical paths are calculated for your project.
Critical path is a set of tasks in a project for which any delay or expansion lengthens the project or causes project deadlines to slip. The critical path determines the project's earliest finish date.
Autoschedule uses the critical path value to determine the tasks that drive the project deadlines and constraints. The critical path is calculated using the dependency sequence and task duration. If you choose to schedule subnets, a separate critical path is calculated and displayed for each subnet and for each task that does not have dependencies.
To calculate the critical path, autoschedule your project or select Tools, Critical Path. You can view the project's critical path in a CPM Network view.
Open Workbench calculates a project's critical path using a two step process. The following rules govern how this two-step process is conducted:
To arrive at the critical path, Open Workbench performs two passes through the dependency network.
The first pass works forward through the network to determine the early start and early end dates for each task in the network, and calculates the longest duration path through the network. The project's reference end date is the project's defined finish date. If you did not define this date, the end date is the early end date of the last task in the network or, if there is more than one branch, the latest of the early end dates of the last task in each branch.
To calculate the early start date for the task's successor(s), Open Workbench starts with the first task in the network and adds the task's duration to the start date. Adjustments are made for gaps or overlaps by adding or subtracting from the duration. The early end date is calculated by adding the task's duration to the early start date. Open Workbench repeats this process for each task in the network.
Note: The successor of a Start-Start dependency has the same early start date as the predecessor. The successor of a Finish-Finish dependency has the same early end date as the predecessor.
The second pass works backward through the network starting from the project finish date to determine each task's late start and late end date. The last task of each branch of the network has a late end date equal to the project finish date. To calculate the late end date for a task's predecessor(s), Open Workbench subtracts the task's duration from the project finish date. Adjustments are made for gaps or overlaps by adding or subtracting from the duration. The late start date is calculated by subtracting the task's duration from the late end date. Open Workbench repeats this process for each task in the network.
Note: The predecessor of a Start-Start dependency has the same late start date as the successor. The predecessor of a Finish-Finish dependency has the same late end date as the successor.
Open Workbench calculates the float for each task by subtracting the early start date from the late start date. Float is the number of days that a task's initiation or completion can be delayed without adversely affecting the project finish date. Float is calculated using the following formula: Late Start - Early Start. Tasks with a float of zero (0) appear on the critical path.
|
Copyright © 2013 CA.
All rights reserved.
|
|