C

CPM
M Sch
hedule Ana
alysis
A
Assessm
ment Points
GOA No. Criteria name Required result
1. Data Quality
36 1.1 Actual Finish Before Actual Start Checks for tasks that have actual finish dates before their actual start date. 0 tasks
[9] i An actual finish date should never be before an actual start date. In the real world, you cannot finish something before you start!
Only effort tasks are examined. The score is calculated by dividing tasks with actual finish dates before the actual start dates by the number of 
effort tasks.

! One or both of those actual dates must be incorrect. Next Steps:
‐ Investigate by checking with the person who reported those dates.
‐ Correct the actual dates that are incorrect.
37 1.2 Actual Start / Finish Dates in the Future Checks for tasks that have an actual start or actual finish date in the future. 0 tasks
[9] i Tasks have planned dates and actual dates. 
An actual start or actual finish date is the record of when a task actually started of finished, so we can only believe this if the date is in the past. For 
example, if someone tells you that they plan to run five miles on May 17th, and May 17th is two days from now, you would probably believe them. 
If, however, they told you that they actually ran five miles on May 17th (two days from now), you wouldn't believe them, since that day has not 
happened yet. While it may in fact happen two days from now, it cannot be true at this moment.
In this context, we do need to define what the future means:
Does the Project Have a Status Date? The Future Means:
No Any date after right now.
Yes Any date after the status date
When the project has a status date, the scheduler is saying that the information in the schedule was updated at that point in time. While time has 
elapsed since the status date, it is presumed that the schedule has not been updated in that time, so the future is defined as any time after the 
schedule was last updated.

Schedule Analysis ‐ Assessment Points Page 1 of 26
GOA No. Criteria name Required result
! Actual dates should only be recorded if the event (task start or finish) truly happened, and for this to be true, the date must be in the past. If an 
actual date was recorded in the future (after today or after the status date), it should be given attention. 
Next Steps:
‐ Investigate by checking with the person who reported these dates. Was it a data entry error? Is the schedule maintainer trusting that the date will 
in fact happen on the future day that was entered?
‐ Correct the actual dates that are incorrect. 
7 1.3 Baseline Vertical Schedule Integration Checks to see if the Baseline Start and Baseline Finish of Summary Tasks are correct. 0 tasks
i Most scheduling programs allow you to organize tasks in a branched tree hierarchy, mirroring the work breakdown structure if it exists. In this 
hierarchy, summary tasks serve as parent placeholders for the tasks that are below them in the hierarchy.

In a "bottom up" schedule (like Microsoft Project), the only information that should be entered for a summary task is "documentation" information 
like its name. Everything else (dates, cost, duration, work, etc.) should be determined by the values of its immediate children tasks. For example, 
The Baseline Start date of Task B in the diagram above should be determined by the earlier of the Baseline Start dates of Tasks D and E. The 
Baseline Finish of Task B is determined by the later of the Baseline Finish dates of Tasks D and E. That way, Task B represents the Baseline Start and 
Baseline Finish of the tasks below it; it "summarizes" those tasks, which is why Task B is called a Summary Task.
The dates from Tasks D and E are said to "roll up" to task B, just as the dates from tasks B and C roll up to Task A. Scheduling applications like 
Microsoft Project automatically perform this rollup calculation. It would be quite time consuming to do this manually every time a change was 
made.
The schedule can be erroneously changed so that there is a mismatch in the rolled up dates. For example, if a scheduler manually changes a date, it 
may be different from the one that is automatically calculated by the scheduling application.
This criteria checks to make sure that the Baseline Start and Baseline Finish dates for each summary task are correct. The Baseline Start date of a 
summary task should correspond to the earliest Baseline Start date of its children tasks. Similarly, the Baseline Finish date of a summary task should 
correspond to the latest Baseline Finish date of its children.
If it doesn't, the summary task will be flagged for investigation.

! For each Summary Task that is incorrect: 
‐ Examine the Baseline Start and Baseline Finish dates to verify that one or both is incorrect.
‐ Check with the scheduler; are they overwriting the calculated values for these fields? If so, that practice should be discontinued. Baseline dates 
should not be manually modified, and summary task values should be calculated by the scheduling application.
‐ Correct the actual dates that are incorrect. 

Schedule Analysis ‐ Assessment Points Page 2 of 26
GOA No. Criteria name Required result
34 1.4 Project Has Status Date Checks to make sure the project has a status date.
i This criterion checks to make sure the project has a status date. Without a status date, you don't know when the schedule was last updated, or how 
current the information in the schedule is. That's the reason why it's a good practice to set the Status Date every time the schedule is updated. 

! If the schedule does not have a status date:
‐ Update the status of any tasks that are in progress and make sure that future tasks are in sync with the project plan.
‐ Set the status date for the project. 
1 1.5 Tasks with missing WBS Checks for tasks that are missing a WBS code. <2% 2‐5% >5%
i Every task in your schedule should have a WBS code assigned. The WBS (work breakdown structure) organizes all of the work into work packages.  <2% 2‐75% >75%
Each work package should have a unique WBS code which identifies the work. WBS codes are used to track cost, performance, and technical data 
related to the work. If a task is missing a WBS code, it's possible that the task will not be included in reports, making the reports inaccurate and 
incomplete.
(For Microsoft Project users): Microsoft Project automatically assigns a WBS code to each task, but if a custom field is being used for the WBS code, 
then it's possible that a task could have a missing WBS code.
! For each task that is missing a WBS code: 
‐ Look up the correct WBS code and assign it to the task. 
‐ Understand why and how the WBS code was missing, and see if the same problem might be happening in other places and how it might be 
prevented in the future. 
14 1.6 Tasks Without Assigned Resources Checks for tasks with work remaining that do not have assigned resources. <5% 5‐10% >10%
[10] i This criterion checks for tasks that have work remaining but do not have any resources assigned.  <5% 5‐75% >75%
If a task involves real work, the work must be done by someone (a person), something (e.g. equipment), or both. If no resources are assigned to the 
task, it bears closer investigation. Tasks without real work (e.g. milestones, summary tasks) are ignored, as are tasks where the work is already 
complete.
! For each task that is flagged by this check, determine which resources should be assigned to the task. Once that information is known, make the 
resource assignments. Follow your organization's change control process if one exists.
13 Summary Tasks with Resources Checks for summary tasks with resources assigned. 0 tasks
i Summary tasks are used as a container for other tasks. Because they aren't really tasks, they should not have resources assigned to them. Another 
reason it's not a good practice to assign resources to summary tasks is that scheduling applications like Microsoft Project behave unpredictably 
when resources are assigned to summary tasks. This can cause disruption to the calculation of an accurate critical path.

! If summary tasks are identified that have resources assigned to them:
‐ Remove the resource assignments.
‐ Discontinue the practice of assigning resources to summary tasks. 
‐ If necessary, educate other schedulers of the pitfalls of this practice. 
42 1.7 Tasks Missing Baseline Dates Checks for tasks that are missing a baseline start or baseline finish. 0 tasks
[11] i In the same way that you cannot track spending performance without a budget, trying to track schedule performance without a baseline is very 
difficult. This criteria finds the tasks that are missing a Baseline Start or Baseline Finish value. Without baseline dates, you don't have a record of 
dates according to the official "plan", and you cannot effectively compare actual dates against planned dates.
! If you discover that a small number of tasks are missing a baseline, you should attempt to find the original dates from other project documents and 
set the baseline dates for those tasks. If you discover that all of your tasks are missing baseline values, you should set the baseline for all tasks to 
their current planned values. Setting a baseline in mid‐project is better than not setting one at all.

Schedule Analysis ‐ Assessment Points Page 3 of 26
GOA No. Criteria name Required result
19 1.8 Dangling Activities Checks for tasks that are dangling activities. 0 tasks
i A dangling activity is an activity that can grow (have its duration increase) without easy detection.  <2% >2%
There are two cases where a task can be a dangling activity:
1‐ No Predecessors are Start‐to‐Start or Finish‐to‐Start. In this case, no predecessors are connected to the Start Date of the task.
2‐ No Successors are Finish‐to‐Finish or Finish‐to‐Start. In this case, no successors are connected to the Finish Date of the task. 
In both cases, the task is not integrated into the schedule network adequately, and it's possible that the task's duration could increase without 
being detected easily. Dangling tasks may also interfere with the proper calculation of the critical path.

! For each task that is flagged as a dangling task: 
‐ If no predecessors are Start‐to‐Start or Finish‐to‐Start, find the real‐world predecessor that affects the start date of the task and link it properly to 
the task. We recommend using a Finish‐to‐Start predecessor.
‐ If no successors are Finish‐to‐Finish or Finish‐to‐Start, find the real world successor that would be affected by this task and link it properly to this 
task. We recommend using a Finish‐to‐Start successor.
8 [4] Tasks With Start‐to‐Finish Relationships 0 tasks

Schedule Analysis ‐ Assessment Points Page 4 of 26
GOA No. Criteria name Required result
2. Performance
39 2.1 Baseline Execution Index The Baseline Execution Index (BEI) is a ratio calculation: the number of tasks that finished  <0,85 0,85‐ >0,95
divided by the number of tasks that were planned to be finished. 0,95
[14] i This criteria is one way to quickly check how a project is performing. It counts the tasks that have finished (based on the Actual Finish value) and the 
tasks that were supposed to be finished (based on the Baseline Finish value). By dividing the finished tasks by the tasks that were supposed to be 
finished, you get a crude but helpful assessment of the "on time" completion rate of tasks.
When do we count a task as "should be finished?" When the Baseline Finish occurs on or before the status date, we include it in the count. When 
do we count a task as "finished?" When the Actual Finish has a date set. Summary tasks are always excluded from both counts.
Do we only consider tasks that should have finished when counting tasks that finished? No. If a task finished, it will be included in the count 
whether it was supposed to have finished or not. 
How are tasks without a Baseline Finish counted? For the purposes of the criteria calculation, they are excluded from both counts. Note: The 14 
Point assessment tool treats tasks missing a Baseline Finish differently. 
A couple of examples will illustrate how the Baseline Execution Index is calculated. 
Suppose that 100 non‐summary tasks have a baseline finish before the status date. 92 non‐summary tasks have an Actual Finish date set. The 
Baseline Execution Index will be 0.92 (92 divide by 100).
Suppose that 2000 non‐summary tasks have a Baseline Finish before the status date, and 2300 non‐summary tasks have an Actual Finish date set. 
The Baseline Execution Index will be 1.15.
With the BEI, lower values are worse, and higher values are better. A value of 1.0 means that the number of tasks that finished match the number 
of tasks that were supposed to be finished. Does that mean the project is exactly on schedule? Not necessarily, because we're just considering task 
counts. Short tasks that finished ahead of schedule are given the same weight (they count as one task) as long tasks that are behind schedule. 

! It's not uncommon for the BEI to fall below 1.0, but it's a good idea to set a "low water mark" threshold and investigate when the BEI falls under 
that threshold. Default threshold is 0.95.
Next Steps:
‐ If the BEI is below your threshold, examine the tasks that are behind schedule and understand the cause of the delays.
‐ Compare against previous BEI results and understand whether there is a trend; are BEI values getting progressively lower? What can be done to 
improve the situation?
‐ If tasks are missing baseline values, make sure this is corrected the next time the schedule is baselined.
Schedule Analysis ‐ Assessment Points Page 5 of 26
GOA No. Criteria name Required result
2.2 CPI Too High Checks to see if the CPI (Cost Performance Index) is above or below a customizable  <0,95 0,95‐ >1,3
2.3 CPI Too Low threshold. 1,3
i A project that is under budget is usually a good thing, but if it's too much underbudget or overbudget, it bears investigation. 
The CPI (Cost Performance Index) is an earned value measurement that shows whether a project is over budget or under budget. It looks at the 
work that was actually performed and compares the planned cost of that work against the actual cost of the work. 
If the CPI is less than 1.0, the planned cost was less than the actual cost, so the project is over budget. If the CPI is greater than 1.0, the planned cost 
is greater than the actual cost, so the project is under budget.
If the CPI is a few percentage points under budget, it's probably okay, but what if the project was 50% under budget? You would want to investigate 
and understand why.
! If the calculated CPI was above the threshold, everything may be okay, but you'll want to investigate and understand the reasons why the project is 
under budget.
‐ Was it a case of overinflated estimates? If so, can you adjust the estimates of remaining tasks to be more in line?
‐ Is quality suffering? Was less skilled labor brought in? Were lower quality materials used?
‐ If the reasons for being under budget are legitimate, are there best practices that can be shared with other project teams in your organization? 

35 2.4 Delinquent Tasks Checks for tasks that missed their Start or Finish dates. 0 tasks

[9] i Delinquent tasks are tasks that missed either their Planned Start date or their Planned Finish date (or both). The planned dates that are flagged 
cannot be trusted, since they are in the past.
Summary tasks are excluded. If a task has a Planned Start before the status date, and it hasn't started (there is no Actual Start date), it is counted as 
a delinquent task. If a task has a Planned Finish date before the status date, and it hasn't finished (there is no Actual Finish date), it is also counted 
as a delinquent task. 
If there is no status date, the calculation is as above except the status date is considered to be the current date.

! With each task found to be delinquent, there are two issues. 
1. The task is behind schedule, and the reasons for the delay should be investigated.
2. The schedule cannot be trusted. The Planned Start or Finish (or both) cannot be met, because the date is in the past. The schedule should be 
adjusted (following proper change authorization) to reflect dates that can be met.   
Schedule Analysis ‐ Assessment Points Page 6 of 26
GOA No. Criteria name Required result
38 2.5 Out of Sequence Tasks Checks for successor tasks that have violated a relationship it has with a predecessor. 0 tasks
i This criterion looks at the relationships (links) between tasks. For each link, a check is made on the successor task to make sure it hasn't violated its 
relationship with the predecessor. If it violated the relationship, it is said to be out of sequence.
The test for whether the successor is out of sequence depends on the relationship type.
Relationship Type Out of Sequence
Finish to Start The successor started, the predecessor has not finished.
Start to Start The successor started, the predecessor has not started.
Finish to Finish The successor finished, the predecessor has not finished.
Start to Finish The successor finished, the predecessor did not start.

! For each out of sequence successor, investigate by checking with the person responsible for the start of the successor.
‐ If the reason for the relationship is legitimate, what are the consequences of Task B starting out of sequence?
‐ If there are no consequences of the task being out of sequence, are there other relationships in the schedule that aren't necessary? Can they be 
removed to simplify the schedule? 
40 2.6 Predecessors Complete, Task Not Started Checks for tasks that haven't started but whose predecessors are complete. >10% 10‐15% >15%
i Typically, with Finish‐to‐Start relationships, a task may begin when all of its predecessors have completed. This check looks for tasks that haven't  >10% 10‐75% >75%
started despite the fact that all of its predecessors are complete.

Schedule Analysis ‐ Assessment Points Page 7 of 26
GOA No. Criteria name Required result
! For each task that is flagged, investigate by checking with the person responsible for the start of the task.
‐ Are the reasons for the finish‐to‐start relationships legitimate?
‐ Why hasn't the task started? 
‐ When will the task start?  
‐ What is the impact of a late start?
41 2.7 Should Start Tasks Reports the number of tasks that were scheduled to start in the past. Statistic
i This criterion is actually just a statistic showing the percentage of tasks that were scheduled to start in the past. It does not distinguish between  <25% 25‐75% >75%
whether the tasks actually started or not. It can be used as a measure of how far along into the planned work you are.
Non‐summary tasks that have a Planned Start date in the past are counted, as well as split tasks that have a Resume date in the past. The 
percentage is determined by dividing the count against all non‐summary tasks.
At the beginning of a project, the percentage should be zero. As time passes, it will increase, eventually reaching 100% at the end of the project.

2.8 SPI Too High Checks to see if the SPI (Schedule Performance Index) is above or below a customizable  <0,95 0,95‐ >1,3

2.9 SPI Too Low threshold. 1,3
i A project that is ahead of schedule is usually a good thing, but if it's too much ahead of schedule, it bears investigation. 
The SPI (Schedule Performance Index) is an earned value measurement that shows whether a project is ahead of schedule, (SPI > 1), on time (SPI = 
1), or behind schedule( SPI < 1).  
If SPI is 1.2, 120% of the planned portion in the scheduled time was completed, so the project is running ahead of schedule. 
If the SPI is a few percentage points ahead of schedule, it's probably okay, but what if the project was 50% ahead of schedule? You would want to 
investigate and understand why.
! If the calculated SPI was above the threshold, everything may be okay, but you'll want to investigate and understand the reasons why the project is 
ahead of schedule.
Was it a case of overinflated duration estimates? If so, can you adjust the duration estimates of remaining tasks to be more in line?
Is quality suffering?
If the reasons for being ahead of schedule are legitimate, are there best practices that can be shared with other project teams in your organization? 

Schedule Analysis ‐ Assessment Points Page 8 of 26
GOA No. Criteria name Required result
3. Statistical
43 3.1 Efforts Tasks Checks to make sure there is an adequate percentage of effort tasks in the schedule. <64% 64‐68% 68‐92% 92‐96%
i This criterion simply does a statistical check.  <10% 10‐75% >75%
Effort tasks are tasks that have real work associated with them. While good schedules have non‐effort tasks (e.g. summary tasks, milestones), as a 
best practice a large portion of the tasks should be effort tasks. This criteria checks to make sure the portion of effort tasks is above an acceptable 
threshold.
! If the percentage of effort tasks is flagged as too low, ask the following questions:
‐ Is it a small schedule? With extremely small schedules, even a small amount of milestones and summary tasks can cause this check to trigger. In 
that case, this check can probably be ignored.
‐ Are there too many summary tasks? If so, the schedule might be "overorganized." Perhaps some groups of activities can be consolidated 
underneath one summary task.
‐ Are there too many milestones? If so, ask whether all of the milestones are meaningful and whether they really need to be tracked. 
47 Critical Tasks Reports on the percentage or the number of critical tasks Statistic
20 3.2 Incomplete Critical Tasks Reports on the percentage of incomplete tasks that are critical. Statistic
i This criterion simply reports a statistic. It isn't checking the schedule against any criteria. <15% 15‐75% >75%
Incomplete critical tasks are tasks that haven't finished and are part of the schedule's critical path. This statistic reports the percentage of 
incomplete tasks that are critical. 
This statistic is a general indicator of the importance of the remaining work. 
! It's a good practice to watch this statistic over the course of a project. It helps you understand the nature of the remaining work.
46 3.3 Incomplete Tasks Reports on the percentage of effort tasks that are incomplete. Statistic
i This criterion simply reports a statistic. It isn't checking the schedule against any criteria.
Incomplete tasks are tasks that haven't finished. This statistic reports the percentage of effort tasks that are incomplete. 
This statistic is a general indicator of the percentage of the total work that remains to be performed. The score should start at 100% at the 
beginning of the project and become lower as the project progresses, reaching 0% at the end of the project. 
! It's a good practice to watch this statistic over the course of a project. It is one way to track progress of the project. When compared against 
expected values, you may discover performance problems in the project.
If this score ever increases, investigate to understand the reason. It is possible that scope was added to the project.
44 3.4 Milestone Tasks Checks to make sure that the percentage of milestones in the schedule isn't too high. <7% 7‐15% 15‐25% 25‐33%
i This criterion simply does a statistical check.  <20% 20‐75% >75%
Milestones are tasks that mark important events. While good schedules have milestones, as a best practice the percentage of milestones should not 
be too high. This criteria checks to make sure the percentage of milestones is below an acceptable threshold.
! If the percentage of milestones is flagged as too high, ask the following questions:
‐ Is it a small schedule? With extremely small schedules, even a small amount of milestones can cause this check to trigger. In that case, this check 
can probably be ignored.
‐ Are all of the milestones necessary? Can milestones be removed without decreasing the ability to track progress on the schedule? 

Schedule Analysis ‐ Assessment Points Page 9 of 26
GOA No. Criteria name Required result
45 3.5 Summary Tasks Checks to make sure there is an adequate percentage of summary tasks in the schedule. <7% 7‐13% 13‐27% 27‐33%
i This criterion simply does a statistical check.  <20% 20‐75% >75%
Summary tasks are used as a container for other tasks. They are needed for reporting and tracking. While good schedules have summary task, as a 
best practice the percentage of summary tasks should not be too high. This criteria checks to make sure the portion of summary tasks is below an 
acceptable threshold. 
! If the percentage of summary tasks is flagged as too high, ask the following questions:
‐ Is it a small schedule? With extremely small schedules, even a small amount of summary tasks can cause this check to trigger. In that case, this 
check can probably be ignored.
‐ Is the schedule "over organized?" Are all of the summary tasks necessary? Perhaps some groups of activities can be consolidated underneath one 
summary task. 

Schedule Analysis ‐ Assessment Points Page 10 of 26
GOA No. Criteria name Required result
4. Critical Path Quality
2 4.1 Missing Predecessors Checks for tasks that are missing predecessors. <2% 2‐6% >6%
[1] i One of the basic tasks of a scheduling engine is to calculate when tasks can begin. It typically does this by looking at the predecessors of a task.  <2% 2‐75% >75%
Typically, a task can be scheduled to start when all of its predecessors are scheduled to be complete.
When a task has no predecessors, it isn't part of the schedule network. Its start date is either entered manually or assigned to the start date of a 
project. There are potential problems with both cases. Whether it is entered manually or automatically assigned to the project's start date, it raises 
some questions. Is there a good reason for a task to start on that specific date? Is that the best use of the resource on that day? In the real world, 
are there in fact tasks that must finish before this task can start?
In some cases, it's okay for a task to have no predecessors. If you create a milestone representing the start of the project, it will naturally not have 
any predecessors. In general, though, it's a scheduling best practice for tasks to have predecessors.

! For each task that is missing predecessors: 
‐ Investigate why the task's start date is set to its present value. 
‐ Identify whether there are actually tasks that it depends on and link them to the task by setting the task's predecessors.
‐ If there are in fact no predecessors, set the predecessor to a milestone representing the start of the project. Avoid manually setting a start date for 
the task. 
3 4.2 Missing Successors Checks for tasks that are missing successors. <2% 2‐6% >6%
[1] i When a task has no successors, it isn't completely integrated into the schedule network. The information on which tasks are depending on it is  <2% 2‐75% >75%
missing. It raises an important question. If no tasks are depending on a task completing, then why is being completed at all? 
In some cases, it's okay for a task to have no successors. If you create a milestone representing the end of the project, it will naturally not have any 
successors. In general, though, it's a scheduling best practice for tasks to have successors.

Schedule Analysis ‐ Assessment Points Page 11 of 26
GOA No. Criteria name Required result

! For each task that is missing successors:   
Identify whether there are actually other tasks that depend on this task and link them to this task by setting this task's successors.
If there are in fact no successors, set this task's successor to a milestone representing the end of the project. 
6 4.3 Tasks with Constrained Dates Checks for tasks that have constraints. <5% 5‐10% >10%
[5] i A common rule of a schedule: any delay to a task on the critical path will cause a delay to the project’s end date.  This is how it should be; the rule  <15% 15‐75% >75%
applies when you have a "good" schedule. It applies when you have a critical path which "flows" properly.
Tasks with hard constraints can cause this rule to be broken and should be avoided. They have the effect of anchoring a start or finish date to a 
specific date. The scheduling engine has the primary job of calculating start and finish dates for the tasks. It won't be able to do its primary job 
properly when it encounters constraints. When an earlier task on the critical path slips, later critical tasks with constraints won't "move" because of 
the constraint. The critical path won't "flow" as it should. You won't learn the real world impact of the slip. For this reason, the use of constraints 
should be minimal and avoided whenever possible.
Soft constraints do not impact the critical path in the same way, but they may be used improperly and their use should be investigated.

Schedule Analysis ‐ Assessment Points Page 12 of 26
GOA No. Criteria name Required result
! For each task with a constraint, investigate why the constraint exists and how it might be removed. Ask the following questions:
‐ Why was the constraint added? 
‐ Is there a "real world" reason for the constraint?
‐ What would the effect be of removing the constraint?
9 [5] Tasks with Hard Contraints 0‐75% >75%
11 [2/3] Tasks with Predecessors containing Leads or Lags <5% 5‐75% >75%
12 [2/3] Tasks with Successors containing Leads or Lags <5% 5‐75% >75%
31[7] 4.4 Tasks with Total Float < ‐200 days Checks for tasks that have a total float value below a certain threshold. 0 tasks
33[7] 4.5 Tasks with Total Float < ‐20 days Checks for tasks that have a total float value below a certain threshold. <10% 10‐15% >15%
<5% 5‐75% >75%
30[6] 4.6 Tasks with Total Float > 200 days Checks for tasks that have a total float value above a certain threshold. 0 tasks
32[6] 4.7 Tasks with Total Float > 30 days Checks for tasks that have a total float value above a certain threshold. <25% 25‐70% >70%
i This criterion checks for tasks that have a total float value above a specific threshold. The threshold is specified for the criterion. <25% 25‐75% >75%
When a task has positive float, the amount of work remaining is less than the amount of remaining time. The task could slip by the amount of total 
float without affecting the end date of the schedule.
By definition, non‐critical tasks have positive total float, and that's perfectly okay. If a large number of those tasks have a "high" total float that 
exceeds certain levels, it's possible that there are inefficiencies in the schedule; there might be a way to reorder the schedule that will reduce costs 
or make more sense.

! For each task that has excessive positive float, ask the following questions: 
‐ What is the underlying reason for the high total float value?
‐ Could the task be scheduled later at a lower cost?
‐ Is there is significant underutilization for the resources assigned to the task, could other work be scheduled during that float period? 

Schedule Analysis ‐ Assessment Points Page 13 of 26
GOA No. Criteria name Required result
5 4.8 Tasks Without Finish‐to‐Start Predecessors Checks for tasks that are missing finish‐to‐start predecessors. <10% 10‐20% >20%
[4] i This check will uncover tasks that do not have a finish‐to‐start predecessor. This may be the case if the task has no predecessors, or it might have  <15% 15‐75% >75%
predecessors that aren't finish‐to‐start. 
If the task has no predecessors, see the check for Missing Predecessors for an explanation of why this may present a problem.
If the task has predecessors, but none of them are finish‐to‐start, the task will be flagged in this check. Typically, most predecessor relationships 
should be finish‐to‐start. There are some cases where using another type of relationship is correct, but in many cases non‐finish‐to‐start 
relationships are used improperly. When they are used improperly, the critical path will not be calculated properly.
! For each task that has no predecessors: 
‐ Investigate why the task's start date is set to its present value. 
‐ Identify whether there are actually tasks that it depends on and link them to the task by setting the task's predecessors.
If there are in fact no predecessors, set the predecessor to a milestone representing the start of the project. Avoid manually setting a start date for 
the task. 
‐ For each task that has predecessors, but none of them are finish‐to‐start: 
Investigate whether the relationship type (e.g. start‐to‐start, finish‐to‐finish, start‐to‐finish) is being used properly.
‐ If it isn't being used properly, correct the relationship type to the one that should be used. 
21 Schedule Criticality Checks for t Percent of critical activities with respect to remaining ones <15% 15‐75% >75%
i In general, assessing the quality of the Base Schedule and its critical path by counting the number of critical activities against the total activities is 
not useful. The number of critical activities will depend on the visibility required to manage the schedule and the risk profile of project. However, as 
a guidance if the ratio of critical path activities to the total activity count (i.e. SCI) is more than 50 percent, then the schedule may be overly serial 
and resource limited.
24 [8] Critical Tasks with Duration > 66 days <75% >75%
23 [1] Critical Tasks With Missing Predecessors 0 tasks
27 [1] Critical Tasks with Missing Successors 0 tasks
22 [5] Critical Tasks With Constraints 0 tasks
25 [2] Critical Tasks with Predecessors containing Leads 0 tasks
26 [2] Critical Tasks with Successors containing Leads 0 tasks
28 [3] Critical Tasks with Predecessors containing Lags 0 tasks
29 [3] Critical Tasks with Successors containing Lags 0 tasks

Schedule Analysis ‐ Assessment Points Page 14 of 26
GOA No. Criteria name Required result
5. Best Practices
10 5.1 Summary Tasks With Predecessors Checks for summary tasks that are linked with predecessors. 0 tasks
i Summary tasks are used as a container for other tasks. Because they aren't really tasks, they should not be linked with predecessors or successors. 
Doing so can cause unpredictable results in the calculation of planned start and finish dates. This can interfere with the calculation of an accurate 
critical path.

! If summary tasks are identified that have predecessors to them:
‐ Remove the predecessors from the summary tasks and assign the predecessor to the correct task (usually the first task underneath the summary 
task).
‐ Discontinue the practice of linking predecessors with summary tasks. 
‐ If necessary, educate other schedulers of the pitfalls of this practice. 
4 5.2 Summary Tasks With Successors Checks for summary tasks that are linked with successors. 0 tasks
i Summary tasks are used as a container for other tasks. Because they aren't really tasks, they should not be linked with predecessors or successors. 
Doing so can cause unpredictable results in the calculation of planned start and finish dates. This can interfere with the calculation of an accurate 
critical path.

! If summary tasks are identified that have successors assigned to them:
‐ Remove the successors from the summary tasks and assign the successor to the correct task (usually the last task underneath the summary task).
‐ Discontinue the practice of linking summary tasks with successors. 
‐ If necessary, educate other schedulers of the pitfalls of this practice.

Schedule Analysis ‐ Assessment Points Page 15 of 26
GOA No. Criteria name Required result
16 5.3 Task with Duration < 5 days Checks to make sure that the Durations of tasks arenot too small. <25% 25‐35% >35%
i This criterion checks to make sure that the durations of tasks are not below a customizable threshhold.  <25% 25‐75% >75%
Duration is the length of working time that transpires between the beginning and end of a task. If the durations of tasks are too short, your 
schedule may contain too much detail. This can make the schedule unreadable, unmaintainable, and ultimately unusable as a management tool. As 
a project manager, you will spend more time maintaining and updating the schedule than is practical.

! If the duration of a task is flagged as too low, ask the following questions:
‐ Does it need to be tracked as in individual activity, or can it be combined with one or more logically grouped activities?
‐ Is the amount of effort that was estimated too low? 
15 5.4 Task with Duration > 20 days Checks to make sure that the Durations of tasks are not too long. <5% 5‐10% >10%
[8] i This criterion checks to make sure that the durations of tasks are not above a customizable threshhold.  <5% 5‐75% >75%
Duration is the length of working time that transpires between the beginning and end of a task. 
When the duration of tasks is too long, your schedule may contain too little detail. In a schedule with too little detail, real world dependencies and 
milestones might not be recorded in the schedule. It's also possible that tasks can slip or other delays could occur without being detected early 
enough by the project manager. The project manager may become aware of delays on particularly "long" tasks when it is too late to intervene and 
take corrective action.
! If the duration of a task is flagged as too long, ask the following questions:
‐ Can the task be broken up into two or more smaller tasks?
‐ Is the amount of effort that was estimated too high?
‐ If the task cannot be broken up into smaller tasks, are there other methods of detecting whether the task is slipping in time to take corrective 
action? 
17 [8] Task with Duration > 44 days Checks the durations of a task based on criteria thresholds. <5% 5‐75% >75%
18 [8] Task with Duration > 66 days Checks the durations of a task based on criteria thresholds. <5% 5‐75% >75%

Schedule Analysis ‐ Assessment Points Page 16 of 26
GOA No. Criteria name Required result
6. MS Project 2010+
6.1 Inactive Task Count Finds tasks that are marked as inactive (Project 2010 and after).
i Inactive tasks, a feature of Project 2010 and after, are similar to tasks that have been deleted, except they can be brought back into the schedule by 
marking them as active. Inactive tasks do not affect any other tasks in the schedule, so if they were mistakenly marked as inactive, the schedule 
may not be properly calculated.
! For any tasks found by this criterion, ask the following questions:
‐ Should the task be inactive? Was it mistakenly marked as inactive?
‐ Can the task be deleted instead? Inactive tasks are visible, so if the task won't ever be made active in the future, it might be better to delete the 
task instead.
6.2 Manual Task Count Checks for tasks that are manually scheduled (Project 2010 and later).
i In Project 2010, manually scheduled tasks were introduced. A manually scheduled task is a task that was scheduled by a person and not the 
scheduling engine in Microsoft Project. Microsoft Project will not calculate start and finish dates for a task that has been manually scheduled, so 
manually scheduled tasks can interfere with the proper calculation of the schedule's critical path. For that reason, they should be avoided or used 
minimally.
! Avoid the use of manually scheduled tasks. For each task that is manually scheduled, assign the proper predecessors and successors, and change 
the task mode to "automatically scheduled."
Change the default scheduling mode to "Automatic" in Microsoft Project's settings.
6.3 Project is Manually Scheduled Checks for tasks that are manually scheduled (Project 2010 and later). 0 tasks
i In Project 2010, manually scheduled tasks were introduced. A manually scheduled task is a task that was scheduled by a person and not the 
scheduling engine in Microsoft Project. This criterion checks to see whether the setting for the default scheduling mode is "manual." Because the 
dates of manually scheduled tasks are not calculated by Microsoft Project, their use is discouraged, because they can interfere with the proper 
calculation of the critical path.

! Change the default scheduling mode for new tasks to "Automatic" in Microsoft Project's settings:

Avoid the use of manually scheduled tasks. For each task that is manually scheduled, assign the proper predecessors and successors, and change 
the task mode to "automatically scheduled."
Schedule Analysis ‐ Assessment Points Page 17 of 26
GOA No. Criteria name Required result
6.4 Warning Task Count A count of the number of tasks in the schedule that have the warning flag set. The warning 
flag is a new field in Project 2010 and later. 
i In Project 2010, a new field called "Warning" was introduced. The warning flag indicates that there may be conflicts or other problems with the 
scheduling of a task. This criterion counts the number of tasks that have warnings.

! To see the warning message(s) for the task, right‐click on task and select "Fix in Task Inspector." The task inspector will show you options for the 
repair of the conflict(s). 
If the task is manually scheduled, you should avoid the use of manually scheduled tasks. For each task that is manually scheduled, assign the proper 
predecessors and successors, and change the task mode to "automatically scheduled."
6.5 Invalid Duration Task Count A count of the number of tasks in the schedule that have a duration that isn't numeric. This 
check only applies to schedules created in Microsoft Project 2010 and later. 
i Before Project 2010, Microsoft Project would only allow valid durations to be entered into the Duration field. The values had a numerical value and 
a unit of time (e.g. "3 days"). Beginning with Project 2010 and the introduction of manually scheduled tasks, Microsoft Project will accept any value 
in the Duration column, including simple text (e.g. "Not yet known").
Because the duration isn't valid, the task cannot be properly scheduled and included in the calculation of a valid critical path. This criterion will find 
tasks that do not yet have a valid (numerical) duration.
! Invalid durations can only occur with manually scheduled tasks. You should avoid the use of manually scheduled tasks. For each task that is 
manually scheduled, assign the proper duration, predecessors and successors, and change the task mode to "automatically scheduled."

Schedule Analysis ‐ Assessment Points Page 18 of 26
GOA No. Criteria name Required result
14‐Points Assessment
[1] Missing Logic This metric helps you see how well the tasks in the schedule are linked together. A  <=5%
schedule with more than 5% of its tasks missing predecessors or successors may indicate 
problems with its logic. The links should be examined to make sure that they make sense.

[2] Have Leads (Negative Lag) Having leads (negative lag) in a schedule makes it harder to analyze the critical path,  0%

distorts the total float in a schedule, and may cause resource conflicts. For these reasons, 
using leads in a schedule is not encouraged and the goal is 0%.
[3] Have Lags Having lags in a schedule makes it harder to analyze the critical path and can be used to  <=5%
manipulate float or constrain the schedule. The goal is 5% or less.
[4] Relationship Types The Finish‐to‐Start relationship should account for at least 90% of the links between tasks.      FS =>90%
Finish‐to‐Finish and Start‐to‐Start relationships should be used sparingly (goal: less than      FF+SS <=10%
10% combined). Start‐to‐Finish relationship types should only be used with good      SF = 0%
justification (goal: 0%).
[5] Hard Constraints The use of Hard Constraints prevent the schedule from being driven by links and should  <=5%
only be used with good justification. The number of tasks with hard constraints should not 
exceed 5%.
[6] High Float If more than 5% of tasks have float higher than 44 working days, the network might not  <=5%
have the proper logic.
[7] Negative Float If more than 5% of tasks have negative float (less than 0 working days), there should be a  <=5%
corrective action plan to mitigate the negative float.
[8] High Duration If more than 5% of tasks have a baseline duration of greater than 44 days, the project may  <=5%
be difficult to manage. The tasks should be broken up into two or more discrete tasks.

[9] Invalid Dates 0%
Invalid Forecast Dates Tasks that haven't yet started should not have projected start or finish dates before the 
status date. If they do, we know already that they're wrong.  The goal is 0%.

Invalid Actual Dates There should not be any actual start dates after the status date.  The goal is 0%.
[10] No Assigned Resources Tasks that have at least one day of duration should have baseline work and/or cost  0%
assigned. Otherwise, cost projections for the project will not be valid. The goal is 0%.

[11] Missed Tasks If more than 5% of tasks were missed, the schedule is not adequately meeting the baseline  <=5%

[12] Critcial Path Test
[13] Critical Path Length Index (CPLI)
[14] Baseline Execution Index (BEI)
plan. Missed tasks are indicated with a Finish Variance greater than 0.
By Changing the early finish (EF) of the stated uncompleted activity which has the latest EF 
to about 600 working days extra, any activity that does not slip in proportion misses a 
necessary relationship.
The critical path length plus the total float of the latest activity divided by the critical path  >=1,0
length.
The Baseline Execution Index measures the tasks that were completed as a percentage of  =>0,95
the tasks that should have been completed per the original (baseline) plan. The goal is to 
have a BEI of 0.95 or greater.

Schedule Analysis ‐ Assessment Points Page 19 of 26
GOA No. Criteria name Required result
BEST PRACTICES
1 Activity Counts The schedule should reflect all activities as defined in the project's work breakdown 
structure (WBS), which defines in detail the work necessary to accomplish a project's 
objectives, including activities to be performed by both the owner and contractors.

Total count and count of remaining tasks by task type of:
43 (3.1) Detail tasks
44 (3.4) Miletsone tasks
45 (3.5) Summary tasks
2 Sequencing All Activities The schedule should be planned so that major project events or milestones can be met. To 
meet this objective, activities need to be logically sequenced—that is, logically linked in the 
order in which they are to be carried out. In particular, activities that must be completed 
before other activities can begin (predecessor activities), as well as activities that cannot 
begin until other activities are completed (successor activities), should be identified. This 
helps ensure that interdependencies among activities that collectively lead to the 
accomplishment of events or milestones can be established and used as a basis for guiding 
work and measuring progress.
2.1 Dependencies determine if the activities in the schedule are missing relationships.   If the start of a task 
has no predecessor or the end of the task has no successor, it can effectively be started or 
finished at any time.   This can be the source of flaws in the critical path.
Total count and count of remaining tasks by task type of:
2 [1] 4.1 Missing Predecessors
3 [1] 4.2 Missing Successors
Missing Both Predecessors and Successors
2.2 Dangling activities determine if the activities in the schedule are "open ended".   If the start of a task has no 
relationship to another task in the network, it can effectively be started at any time. If 
there are no activities that succeed the finish of the activity, this is a dangling finish 
activity.
Dangling activities are typically unintentional and is the result of an error in the network 
logic.  The implications of a dangling activity might be hard to detect because they will not 
push the schedule dates even though the duration increases.
19 (1.8) Total count and count of remaining tasks of:
Start has no predecessor
Finish has no successor
2.3 SF Links Dtermine If an activity has Start‐To‐Finish links. Typically, most predecessor relationships 
should be finish‐to‐start. There are some cases where using another type of relationship is 
correct, but in many cases non‐finish‐to‐start relationships are used improperly. When 
they are used improperly, the critical path will not be calculated properly.
8 [4] Total count of:
Activities with Start‐To‐Finish Links

Schedule Analysis ‐ Assessment Points Page 20 of 26
GOA No. Criteria name Required result
2.4 Summary Links Summary tasks are used as a container for other tasks.  Because they aren't really tasks, 
they should not be linked with predecessors or successors. Doing so can cause 
unpredictable results in the calculation of planned start and finish dates. This can interfere 
with the calculation of an accurate critical path.
10 (5.1) ‐ 4 (5.2) Total count of:
Summary Links
2.5 Convergence The convergence check looks for several parallel tasks that come together at a single 
successor.  High convergence may lend itself to a riskier critical path since any number of 
tasks that slip could put the successor in jeopardy.  Path convergence is quite common to 
find as a project unfolds and it can cause for confusion if not handled carefully by the 
project team.
Max of count number of predecessors for non‐summary remaining tasks
Max convergence
2.6 Constraints Constraints and lags should be used sparingly. There may be legitimate reasons for using 
constraints, but each constraint should be investigated.  Constraints should be minimized, 
because they impose a movement restriction on tasks and can cause false dates in a 
schedule.
6 [5] (4.3) Total count for Detail Taks and Milestone by Constraint type of:
As Soon As Possible (no constraints)
Start No Earlier Than
Finish No Later Than
As Late As Possible
Must Finish On
2.7 Active SNET Constraints Start‐no‐earlier‐than (SNET) constraints might reflect the availability of funding or a 
weather limitation and may be logical.  Be sure documentation is available to justify this 
constraint.
A SNET constraint affects the early start date and does not allow an activity to start before 
its constraint date.  If an activity's scheduled start date is the same as the SNET date, then 
the SNET constraint is more than likely preventing the activity from starting early.  This is 
what is counted as an "active" constraint.
If a SNET constraint is earlier than the activity's start date, then the activity is not affected 
by the constraint date.  This is considered "not active".
Count for remaining non‐summary Taks of:
Active SNET Constraint
Not Active SNET Constraint

Schedule Analysis ‐ Assessment Points Page 21 of 26
GOA No. Criteria name Required result
2.8 Active FNET Constraints Finish‐no‐later‐than (FNET) constraints are usually artificial and reflect some policy rather 
than a program reality. If the program does not meet these dates, imposing this kind of 
constraint in a computer model of the program schedule might make the schedule look 
good in the computer while the program is in trouble in the field.
A FNET constraint affects the early finish date and does not allow an activity to finish 
before its constraint date.  If an activity's scheduled finish date is the same as the FNET 
date, then the FNET constraint is more than likely preventing the activity from finishing 
early.  This is what is counted as an "active" constraint. 
If a FNET constraint is earlier than the activity's finish date, then the activity is not affected 
by the constraint date.  This is considered "not active".

Count for remaining non‐summary Taks of:
Active FNET Constraint
Not Active FNET Constraint
2.9 Lags Constraints and lags should be used sparingly.  Lags should represent only the passing of 
time on detailed program schedules and should never be used to replace a task, whereas 
in summary schedules used for schedule risk, the lags may have to be longer.  Total float 
that is more than 5 percent of the total program schedule may indicate that the network 
schedule is not yet mature.
11‐12 [2/3] Count for remaining non‐summary Taks of:
Activities with Lags
Activities with Leads
3 Assigning Resources to All Activities The schedule should reflect what resources (e.g., labor and materials) are needed to do 
the work, whether all required resources will be available when needed, and whether any 
funding or time constraints exist.
3.1 Work Resources Resources are people, materials or costs required to complete a task.  Since the 
relationship between tasks and resources is many to many, the ability to have resources 
under or overallocated is likely.
Count of:
Total Resources
Overallocated Resources
3.2 Assignments An empty Work field is an indication of certainly a non‐resourced schedule, and probably 
unrealistic duration estimates.
Count of:
Activities with Resources
14 [10] 1.6 Activies without Resources

Schedule Analysis ‐ Assessment Points Page 22 of 26
GOA No. Criteria name Required result
4 Establishing the Duration of Activities The schedule should realistically reflect how long each activity will take to execute. In 
determining the duration of each activity, the same rationale, historical data, and 
assumptions used for cost estimating should be used. Durations should be reasonably 
short, meaningful, allow for discrete progress measurement, (i.e., 44 working days—two 
working months—or less for near‐ term effort) and have specific start and finish dates. 
However, schedules that contain planning packages and summary planning packages as 
activities will normally be greater than one month in duration until broken into work 
packages and/or specific activities.
4.1 Durations Breaks down incomplete, detail activities by duration.  The purpose is to identify tasks with 
duration that with too long or toos short of a duration.
The two thresholds are 44 days and 66 days.  Durations should be reasonably short, 
meaningful, allow for progress measurement.  44 working is approximately two calendar 
months.  Tasks less than or equal to 44 days are considered reasonable.  Tasks between 44 
and 66 working days (3 working months) should include justification and tasks greater than 
66 working days should be broken up into smaller discrete tasks.

Count for remaining detail tasks by threshold (1 and 44 days) of:
16 (5.3) ‐ 1 day Less Than or Equal To Threshold
17 [8] ‐ 44 days Greater Than Threshold
4.2 Calendars displays the activities that are scheduled to start or finish on a Saturday or Sunday 
(occurring on weekends or holidays).
Count for remaining tasks starting or finishing on :
Saturday
Sunday
5 Horizontal and Vertical Integration The detailed schedule should be horizontally integrated, meaning that it should link 
products and outcomes associated with other sequenced activities. These links are 
commonly referred to as "handoffs" and serve to verify that activities are arranged in the 
right order to achieve aggregated products or outcomes. The IMS should also be vertically 
integrated, meaning that traceability exists among varying levels of activities and 
supporting tasks and sub‐task. Such mapping or alignment among levels enables different 
groups to work to the same master schedule.
5.1 Horizontal Integration displays the activities that are missing successors or predecessors.  This is a dashboard for 
achieving horizontal integration.
Count of remaining non‐summary tasks of:
2 [1] (4.1) Missing Predecessors
3 [1] (4.2) Missing Successors
5.2 Vertical Integration Baseline Vertical Schedule Integration checks to make sure that the Baseline Start and 
Baseline Finish dates for each summary task are correct. The Baseline Start date of a 
summary task should correspond to the earliest Baseline Start date of its children tasks. 
Similarly, the Baseline Finish date of a summary task should correspond to the latest 
Baseline Finish date of its children.
7 (1.3) Baseline Vertical Schedule Integration

Schedule Analysis ‐ Assessment Points Page 23 of 26
GOA No. Criteria name Required result
6 Critical Path Scheduling software should be used to identify the critical path, which represents the 
chain of dependent activities with the longest total duration. Identifying a project’s critical 
path is necessary to examine the effects of any activity slipping along this path. Potential 
problems along or near the critical path should also be identified and reflected in 
scheduling the duration of high‐risk activities.
The checks above are to help identify possible concerns that might undermine the critical 
path.
The checks aim to answer the following questions.
1. Are any activities in the schedule missing logic or constrained without justification?
2. Is the critical path driven by other unusually long duration activities?
3. Is the critical path driven in any way by lags or leads?

Count of remaining non‐summary critical tasks of:
22 [5] Critical Tasks with Constraints
23 [1] Critical Tasks with Missing Predecessors
27 [1] Critical Tasks with Missing Successors
24 [8] Critical Tasks with Duration > 66d
28 [3] Critical Tasks with Predecessors containing Lags
29 [3] Critical Tasks with Successors containing Lags
25 [2] Critical Tasks with Predecessors containing Leads
26 [2] Critical Tasks with Successors containing Leads
7 Identifying Reasonable Float between Activities The schedule should identify the float (or slack)—the amount of time by which a 
predecessor activity can slip before the delay affects the major milestone(s)—so that a 
schedule’s flexibility can be determined. As a general rule, activities along the critical path 
have the least amount of float. Total float indicates how much flexibility there is in the 
schedule to the major milestone(s). Large total float on an activity or path indicates that 
the activity or path could be delayed by the amount of the float without jeopardizing the 
finish date.
To determine if the total float values calculated by the scheduling software are reasonable 
and accurately reflect true schedule flexibility.
Two thresholds are examined, 0 and 100.  The table breaks out tasks with float greater 
than 0 and 100 and tasks with float less than or equal to 0 and 100.  These values attempt 
to isolate tasks with excessive positive and negative float for further examination.  
Negative slack indicates that there is not enough time scheduled for the task and is usually 
caused by constraint dates.
Count for remaining detail tasks by threshold (0 and 100 days) of:
33 [7] 4.5 ‐ 0 day Less Than or Equal To Threshold
30 [6] 4.7 ‐ 100 days Greater Than Threshold

Schedule Analysis ‐ Assessment Points Page 24 of 26
GOA No. Criteria name Required result
8 Schedule Risk Assessment A schedule risk analysis uses statistical techniques to predict a level of confidence in 
meeting a program's completion date. This analysis focuses on critical path activities and 
on near‐critical and other activities, since any activity may potentially affect the program's 
completion date. Like a cost estimate risk and uncertainty analysis, a schedule risk analysis 
requires the collection of program risk data such as:
• risks that may jeopardize schedule success, usually found in the risk register prepared 
before the risk analysis is conducted;
• probability distributions, usually specified by a point estimate of activity durations;
• probability of a risk register risk's occurring and its probability distribution of impact if it 
were to occur;
• probability that a branch of activities might occur (for example, a test failure could lead 
to several recovery tasks); and
• correlations between activity durations.

Schedule risk analysis relies on Monte Carlo simulation to randomly vary the following:
• activity durations according to their probability distributions or
• risks according to their probability of occurring and the distribution of their impact on 
affected activity if they were to occur and
• existence of a risk's or a probabilistic branch's occurring.
The objective of the simulation is to develop a probability distribution of possible 
completion dates that reflect the program and its quantified risks. From the cumulative 
probability distribution, the organization can match a date to its degree of risk tolerance. 
For instance, an organization might want to adopt a program completion date that 
provides a 70 percent probability that it will finish on or before that date, leaving a 30 
percent probability that it will overrun, given the schedule and the risks. The organization 
can thus adopt a plan consistent with its desired level of confidence in the overall 
integrated schedule. This analysis can give valuable insight into what‐if drills and quantify 
the impact of program changes.

In developing a schedule risk analysis, probability distributions for each activity's duration 
have to be established. Further, risk in all activities must be evaluated and included in the 
analysis. Some people focus only on the critical path, but because we cannot know the 
durations of the activities with certainty, we cannot know the true critical path. 
Consequently, it would be a mistake to focus only on the deterministic critical path when 
some off‐critical path activity might become critical if a risk were to occur. Typically, three‐
point estimates—that is, best, most likely and worst case estimates—are used to develop 
the probability distributions for the duration of workflow activities. After the distributions 
are developed, the Monte Carlo simulation is run.

Schedule Analysis ‐ Assessment Points Page 25 of 26
GOA No. Criteria name Required result
9 Updating the Schedule with Logic and Duration The schedule should be continuously updated using logic and durations to determine 
realistic start and completion dates for program activities. The schedule should be 
analyzed continuously for variances to determine when forecasted completion dates differ 
from planned dates. This analysis is especially important for those variations that impact 
activities identified as being in a project’s critical path and can impact a scheduled 
completion date.
lists activities that have date anomalies according to the status date.  If no status date is 
set these metrics cannot be calculated.
• Finish in Past, No Actual ‐  If a task has a Planned Finish date before the status date, and 
it hasn't finished (there is no Actual Finish date), it is counted.
• Start in Past, No Actual ‐ If a task has a Planned Start before the status date, and it hasn't 
started (there is no Actual Start date), it is counted.
• Project Has Status Date – Simply looks for the existence of a status date in the schedule.
• Is at least one in progress activity critical – Examines each activity that has started, but 
has not yet completed to ensure that it is on the critical path (critical = Yes).
• Activities with actual start or finish dates in the future ‐ An actual start or actual finish 
date is the record of when a task actually started of finished, so we can only believe this if 
the date is in the past.  If a task contains an actual start or finish date in the future, it is 
counted.

Count for remaining detail tasks of:
35 [9] (2.4) Finish in Past, No Actual
35 [9] (2.4) Start in Past, No Actual
37 [9] (1.2) Activities with actual start or finish dates in the future
Check (yes/no)
34 (1.4) Project Has Status Date?
20 (3.2) Is at least one in progress activity critical?

Schedule Analysis ‐ Assessment Points Page 26 of 26