04_Scheduling_Requirements_CODIS_May_15.docx
DOCX document 34 KB Posted
- Attached to
- CODIS DEVELOPMENT AND SUPPORT SERVICES
- Solicitation number
- DJF-15-0700-PR-0021749
About this file
Scheduling Requirements
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Final_Round_2_QA.docx | DOCX document | |
| DJF-15-0700-PR-0021749_Amendment_4_7-17-2015.pdf | ||
| DJF-15-0700-PR-0021749_Amendment_3_7-14-2015.pdf | ||
| RFP_DJF-15-0700-PR-0021749_Questions_and_Answers.docx | DOCX document | |
| Amendment_2_7-10-2015.pdf | ||
| Amendment_1_7-9-2015.pdf | ||
| CODIS_DMSS_RFP_V.14_06242015.docx | DOCX document | |
| 01_Cost_Proposal_Format_Tables_CODIS_May_15.xls | XLS spreadsheet | |
| 06_Past_Performance_Questionnaire_CODIS_May_15.docx | DOCX document | |
| 03_Labor_Category_Descriptions_CODIS_May_15.docx | DOCX document | |
| Copy_of_05_Deliverables_Table_CODIS_June_17.xlsx | XLSX spreadsheet | |
| 02_Cost_Format_Instructions_CODIS_May_2015.doc | DOC document |
Show all 12
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
CODIS Development & Maintenance IDIQ RFP – Attachment #4 – Development Plan and Schedule Requirements
Microsoft Project shall be utilized to track status on a weekly basis.
The Development Contractor shall be responsible for maintaining the Integrated Master Schedule for all activities.
The Development Contractor shall submit a monthly schedule file to the PMO within 10 business days after the month end.
As part of the monthly PMR meetings, a walkthrough of the schedule is required. The walkthrough shall cover critical path activities, plus zero (0) and plus three (3) days, and a thirty (30) day look ahead.
The Development Contractor shall support Ad-hoc inquiries from various FBI oversight stakeholders.
The schedule shall include the following key elements:
1. Task – A discrete element of work. Must be deliverable/product-oriented.
2. Milestone – A specific date that marks the completion of a goal, objective, or phase (i.e. Critical Design Review (CDR), IBR, Go Live, Code Freeze, etc.). All deliverables must be identified in the schedule. All milestones should have zero (0) duration.
3. Calendar – Shall complete project and/or resource calendar to reflect standard holidays and different working time.
4. Duration – The length/span of calendar time estimated to complete a task. Always set duration in days.
5. Work – The amount of time scheduled for a resource to complete a task. While duration is the length of calendar time to complete the effort, work is defined as the amount of time to complete the work (ignoring calendar time). For example, a person might need only ten (10) hours to finish his task (Work = ten (10) hrs); however, due to his availability, it may take him five (5) days to complete it (Duration = five (5) days or forty (40) hrs). Always set work in hours.
6. Resource – Can be a person, travel, equipment, HW, SW, etc. needed to complete the effort. For resource staffing, can use labor category for resource identification instead of individual staff name. If labor category is used, another customized field must be established to identify the proposed staff within each labor category. Separate materials and human resources; they should not be loaded on the same task.
7. Resource Rate – Rate per labor category must be identified to generate proper cost estimate for each effort.
8. Resource Leveling – Over-allocation must be resolved on a week to week basis. This requirement may be superseded by any FBI Office of IT Policy Planning policy.
9. Predecessor and Successor – All tasks shall have a predecessor and successor task identified with the exception of initial project start task and project end date milestone. Predecessor and/or successor shall not be linked at summary level.
10. Lags and Leads – Lead is defined as the amount of time overlapping between connected tasks; lag is the delay time between dependency tasks. The amount of lags and leads shall be reasonable. Excessive leads and lags must be explained.
11. Constraint Type – The use of hard constraints such as Must Start On or Must Finish On is highly discouraged and requires approval from PMO. Hard constraints corrupt the calculation of the critical path. The use of Deadline date is a preferred approach. Minimize the use of Finish No Later than or Finish On.
12. Task Type – minimize the use of Fixed Duration as a task type. Recommend fixed unit as default type.
13. Level of Effort (LOE) task – hours for LOE tasks must not exceed fifteen (15)% of total work. Any recurring and meeting related tasks are considered as LOE. In addition, any task longer than 60 calendar days in duration is considered as LOE.
14. Critical Path – Is defined as the longest path of sequenced activities on the schedule. Any delay to these critical path tasks will impact the project end date.
15. External dependencies must be captured and identified.
16. LCM v6.x, the current version is 6.3 should be used as a guide for sequencing, determining required deliverables and meeting required read-ahead times for reviews and boards.
17. Others – Contractor shall enter the file properties for each project.
When submitting the schedule for baseline approval, the contractor shall ensure that no task is showing slippage or late. A checklist shall be submitted along with the Integrated Master Schedule (IMS) to show that the contractor complies with all of the key elements mentioned above.
Once a baselined schedule has been established, the contractor shall establish a disciplined schedule management control and execution process. The IMS shall be updated on a weekly basis to provide detailed insight into project progress and risk assessment.
A schedule variance tracking report shall be submitted monthly to detail any slippage (see Figure 1 as one example).
Schedule Rules of Thumb:
1. Baselined activity cannot be deleted. Any task that is no longer required to be performed or complete (overcome by event) should be closed out properly. Duration is reduced to zero (0) days; status activity as 100% with proper description of the changes. Actual work is listed as zero (0) hours (or actual work expended if OBE’d).
2. Status date must be entered whenever schedule is updated.
3. Schedule status should be updated using Duration, Actual Duration, Remaining Duration, Work, Actual Work, and Remaining Work. Adjustments to those fields automatically calculate % complete field. This is a preferred method to manually inputting data in the % complete field.
4. Start and Finish fields should be properly updated if the current date is no longer valid.
5. Actual Start and Actual Finish fields must be properly updated to identify when an activity is started or completed.
6. A properly updated schedule must be provided to support the earned value reports.
7. The baseline dates and other baseline data elements (i.e., baseline work, baseline duration) cannot be changed or deleted. Any changes to the baseline fields are considered a “re-baseline” action by FBI oversight.
Figure 1 – Example of Schedule Variance Tracking Report
The format of the Schedule Variance Tracking Report can be changed. However, the following data must be captured:
1. WBS ID
2. Name
3. Finish Variance – Difference between current Finish date and Baseline Finish date
4. Status – NOT to use MS Project Status field. This field should be calculated to show which task is on schedule, late, or behind
5. Baseline Start
6. Baseline Finish
7. Start
8. Finish
9. Previous month’s Finish Date
10. Explanation of why task has slipped or changed from previous week’s finish
The Schedule Variance Tracking Report shall be provided for the following period:
1. activities completed in prior period through the end of month current period
2. activities that are planned for the next thirty (30) days image1.png
File details come from the government source that posted it. Updated .