Download Colorado Project Tracking & Reporting Documents as a .PDF file
or
Download Colorado Project Tracking & Reporting Documents in Microsoft Word format.

The purpose of this document is to describe the tracking of Year 2000 compliance projects by the IMC Year 2000 Project Office. The items that will be tracked are particular to the phase of the Year 2000 lifecycle. The Year 2000 project lifecycle consists of six (6) phases:

1. Inventory

2. Assessment

3. Detail Planning

4. Code

5. Test

6. Implementation.

The first two phases, inventory and assessment, were completed by most departments during the period ending July 31, 1997, culminating in a Statewide cost estimate entitled "State of Colorado Year 2000 Cost Estimate" published August 1, 1997.

The IMC Year 2000 Project Office will collect, assess and evaluate Year 2000 Project information received from each State Department. The Departments will be responsible for transmitting the required data to the IMC Year 2000 Project Office on a monthly and quarterly basis. The monthly data will relate to progress towards Year 2000 compliance. Quarterly data will report actual Year 2000 project expenditures and any requested Year 2000 funds. Monthly data will be reported on a project by project basis and rolled up to the department level by both the Department and the IMC Year 2000 Project Office. In addition, project plans will be updated quarterly as needed. Prior reports used the naming convention of system and project synonymously. A project is generally a collection of programs and tasks logically grouped to support a business function, with a single purpose, such as the child welfare system.

The detail planning phase is critical for the State to achieve Year 2000 compliance in 1999. The goal of this phase is to generate solid plans for each department to follow on a project and department basis. This phase is iterative with the assessment phase and, as such, the detail plans will validate the original estimates and schedules as prepared for the August 1, 1997, report entitled, "State of Colorado Year 2000 Cost Estimate".

The plans developed during this phase will form the basis for tracking, reporting and issue management throughout the lifecycle. As the project plan is developed, the analysis and early cost estimate is validated. The IMC Year 2000 Project Office recognizes that the detail planning process may necessitate modifications to the original cost and schedule estimates.

The deliverables of this phase of the Year 2000 lifecycle are six (6) planning documents:

• project inventory document
• detail work plan
• staffing plan
• risk management plan
• test plan
• implementation plan.

The key to successful Year 2000 compliance is diligent planning and follow-through on these plans. Once delivered to the IMC Year 2000 Project Office, these plans must be updated quarterly.

The IMC Year 2000 Project Office requires that each department use a project planning tool in the collection and planning for this phase and throughout the Year 2000 project.

This document delineates project inventories by module name, members, interfaces and components that must be modified on a module by module basis for each Year 2000 compliant project. The Project Inventory Document also identifies logical groupings of programs for coding, testing and implementation tasks or groups for planning purposes. A sample table of contents for a Project Inventory Document can be seen in Appendix A: Project Inventory Document Sample. For cases other than code modification, the Project Inventory Document should identify the scope of the problem.

The project inventory document should contain a verifiable inventory of modules, members, interfaces and components by module. Logical groups will be identified for coding, testing and implementation purposes. It is recognized that these are usually not the same groups throughout the Year 2000 revision lifecycle. For non-programming projects the document should contain a verifiable inventory of software or hardware to be replaced or modified.

The quality measurement criteria for the project inventory document are:

The work plan initially identifies the tasks, resources, milestones and the schedule or sequence of the work to fix and unit test each module, member, or interface listed in the Project Inventory document. In addition, tasks are identified and planned by project through full project implementation. In the case of a non-code modification project, tasks, resources, milestones and the schedule are still applicable.

The detail work plan should be depicted in a Gantt chart format.

Tasks are logical units of work assigned to a resource that when completed by a resource leads to completion of a milestone(s) or project.

Resources are generally people who perform tasks such as programmers, analysts, data base administrators and so forth.

A milestone is a reference point marking a major event in a project, used to monitor the project's progress. It is suggested that there be bi-weekly milestones and those that represent 25, 50 or 75% of the planned tasks. Examples of milestones are end of code and unit test, approve work plan, or staffing complete.

The schedule is the sequence and duration of the tasks necessary to achieve milestones and complete the project.

The Work Plan is created at the project level and must contain the same general sections as the year 2000 lifecycle: inventory, assessment, detailed planning, code/remediation, test and implementation. It is kept in an electronic tool to record hours worked against the tasks of the work plan by individual resource. Refer to Appendix B: Sample Work Plan.

The project work plan should contain several components depending on the particular project. At a minimum the work plan should contain:

• Tasks that describe what will be done.
• Resources identified to do each task.
• Milestones that show progress to the end of each phase and the project.
• A schedule showing the tasks and milestones leading to completion of the work, i.e. a gantt chart.

One of the quality criteria is measurable milestones. It is anticipated that milestones will be demonstrable and spaced at a minimum every two weeks. Examples of a milestone are:

• Plan completion
• Unit Test modules 1 - 10
• Staffing complete
• Milestones that indicate the beginning and end of a phase.
• Milestones that indicate 25%, 50%, 75% and 100% completion of a planned phase.

Other quality criteria of a work plan are:

• A method of calculating actual progress against the original plan.
• A method of aggregating to the department level.
• Reasonable planning for the entire lifecycle.
• Ability to calculate the critical path.

The staffing plan describes the resources required in the work plan, test plan and implementation plan. In addition, the plan indicates resource planned commitments by month for the life of the project schedule. The Staffing Plan is used to ensure that resources are planned, available in a timely manner and properly utilized. The Staffing Plan is produced by most project management tools.. Refer to Appendix C: Sample Staffing Plan for an example.

The staffing plan provides a detailed view of how the department will apply appropriate resources to ensure that each system will be modified, implemented and tested on time and in an orderly fashion.

The staffing plan should contain the types of personnel resources required by phase. Examples of personnel types may be programmer analyst, test plan writer, test plan conductor, technical writer and so forth. Where possible actual names should be used. If the automated timekeeping system is integrated with the project management tool, then it may be possible to enter the rates, generate budgets and also generate actual dollars spent by time period.

The staffing plan should present the types of labor to be used by unit of work (hours, days, weeks). The quality of the plan will be determined by the completeness, relation to work plan and validity of estimates.

The Risk and Issues Management Plan is a list of risks and issues that the project manager can envision will materially affect the success or timing of the work plan. Examples of such risks and issues are attrition of internal staff, shortage of contract help, late delivery of required technical services such as communication links, availability of computer center resources and business deadlines. All risks and issues should have a written plan for resolution as the project manager understands the situation at the time the plan is written. This document is a living document and is continually updated as the project moves through the lifecycle. Refer to the sample in Appendix D: Risk and Issues Management Plan for more information.

The risk management plan should identify known and potential business and technical risks by project. Department-wide risks should also be identified and may be duplicated within the project risks. For each identified risk, there should be a plan for resolution with a timetable to implement.

This plan should identify both technical and business risks. A plan to resolve the risks should be in place. For example, unit testing requires certain system attributes. If these are not in place, an alternative should be provided so that impact to progress or schedule, and thereby cost, is kept to a minimum. Staffing risks should be identified and a plan should be in place for alternative solutions.

Quality is dependent on the completeness of the plan and reality of the proposed solutions.

The test plan is devoted to ensuring that fixed modules will function appropriately. The goal of the test plan is that it must satisfy the compliance criteria to be identified later. The Test Plan should cover three (3) areas:

The Test Plan will ensure that the compliance criteria are being met on a system by system and department-wide basis. Refer to Appendix E: Testing Guidelines & Scenarios for Year 2000 Conversion.

The basic contents of the test plan are the same as the work plan but the tasks are oriented to testing the modified code to prove the system components and the system work without defect. The same applies with hardware upgrades or new hardware; that is, test the new hardware or upgrades to ensure that existing systems function as before and that the new hardware functions properly. The test plan should ensure that the Year 2000 compliance criteria are met and that the integrity of system functionality prior to the Year 2000 modifications has been maintained. The test plan should contain at a minimum the following components:

• Tasks that describe how the test(s) will be done, i.e. test scripts.
• Resources identified to do each task.
• Milestones that show progress to the end of the phase and the project.
• A schedule showing the tasks and milestones leading to completion of the tests.

A quality test plan includes:

• A method of calculating actual progress against the original test plan.
• A method of aggregating or reporting test progress at the department level.
• Integrated software and hardware availability. If new software needs to be acquired, the acquisition process and needed by dates should be so indicated. If new hardware is being acquired and/or software needs to be loaded, tested and deployed, the processes to accomplish this should be apparent.
• Integrated project test plan gantt chart that provides a critical path and dependencies of modules and test steps.
• Complete test plan. This plan should discuss how testing will be conducted and level of coverage to be achieved. The test plan should also provide for creation of test databases and successful test criteria. Mapping of the test plan to the criteria for Year 2000 compliance should be complete.

The implementation plan describes precisely how the Year 2000 compliant system will be introduced into production. The plan delineates timing, user involvement, project resources and department resources. In addition, the plan details how the cutover will be verified to have been successfully and operationally solid.

This plan may be in a project planning tool, a word processing document, or any other product that clearly communicates to the users of the system what you intend to do and what their responsibilities are to get the system functioning to support their business.

A typical implementation plan begins after acceptance test is complete and includes six sections. Tasks necessary to support the approach and decisions made about how implementation should proceed become the plan. There are six sections to the implementation plan.

• Section 1: Cut Over Approach

• Decide Implementation Approach
• User Signoff of Implementation Approach
• Appoint User Implementation Manager
• Section 2: Documentation Update

• Decide Documentation Set
• Construct/Update Documentation Set
• User Approval of Documentation Set
• Publish Documentation Set
• Section 3: User Training

• Decide /Design User Training
• Construct/Update User Training
• Conduct User Training
• Section 4: Convert Files

• Section 5: Public Relations and System Cut Over

• Section 6: Post Implementation Support

This section purposely left blank.

All departments are responsible to report Year 2000 progress on a monthly and quarterly basis to the IMC Year 2000 Project Office. The monthly report provides metrics about the activity and progress of each project. The quarterly report shows information about the cost impact of department Year 2000 efforts. Refer to Appendix F: Monthly Project Status Reporting, for the layout of the required monthly project status reports. Refer to Appendix G: Quarterly Department Financial Reporting for quarterly reporting formats.

Prior to submitting the first Monthly Progress Report for a project, monthly base estimates must be submitted to the IMC Year 2000 Project Office. The Project Base Estimates Report requires an estimate by month for the project duration of Labor Hours, Milestones, Task Starts and Task Completes. Refer to report "Project Base Estimates Report" in Appendix F for report layout. This baseline data will be used for comparing against project progress. The fields to be included on this report are:

On a monthly basis, each department will complete a "Department Monthly Project Progress Report". It is understood that some of the requested data are not applicable to each department or to every project and are not applicable across the Year 2000 project lifecycle. Exceptions must be obtained through the IMC Year 2000 Project Office.

The name of the Department and the Reporting Period (mm/yyyy) being reported should be in the header of the reporting form.

The report should contain one line for each of the Department's Year 2000 projects. The following ten fields should be provided for each project:

1. Name of the Project.

2. Actual labor hours worked during the Reporting Period.

3. Estimated labor hours remaining to complete the project.

4. Number of actual milestones completed during the Reporting Period.

5. Estimated number of milestones remaining to complete the project.

6. Actual number of tasks started during the Reporting Period.

7. Estimated number of tasks remaining to be started to complete the project.

8. Actual number of tasks completed during the Reporting Period.

9. Estimated number of tasks remaining to be completed to complete the project.

10. Estimated completion date of the project as of this Reporting Period.

Refer to Appendix F: Monthly Project Status Reporting for the required report format for these two reports.

5.2 Quarterly Reporting

Each department will provide to the IMC Year 2000 Project Office requested funds, actual expenses and plan updates on a quarterly basis.

5.2.1 Requested Funds

Quarterly, each department requiring funds for the next quarter, will provide to the IMC Year 2000 Project Office a requested funds form. Requested funds will be delineated by cost category for the upcoming quarter. Estimates to complete for the current quarter must be supplied with the request. For example, requests for funds for the quarter beginning in January will need to include estimates of actual expenditures by cost category for the current quarter (quarter in which the request is prepared) or in this example the quarter ending in December. Requests will provide Year 2000 expenditures for the following cost categories:

• Internal Labor
• External Labor
• Software Costs
• Hardware Costs
• Project Costs
• Other Costs

5.2.2 Actual Expenditures

Actual expenditures for Year 2000 projects will be reported quarterly by cost category. The cost categories are:

• Internal Labor
• External Labor
• Software Costs
• Hardware Costs
• Project Costs
• Other Costs

5.2.3 Plan Updates

Quarterly plan updates will be submitted to the IMC Year 2000 Project Office. The plans are:

• project inventory document
• detail work plan
• staffing plan
• risk management plan
• test plan
• implementation plan.

It is recognized that some of these plans may not have changed since the prior quarter; in this case please notify the IMC Year 2000 Project Office that there has been no change for that particular plan.

Appendix G: Quarterly Department Financial Reporting, shows a sample quarterly project financial report to be used for requested funds and actual expenditure reporting.

5.3 Project Evaluation Ratings

The Year 2000 Project Office will report three ratings based on the deliverables of the detailed planning phase and monthly and quarterly reports submitted by the departments. These three ratings are the Year 2000 Project Progress Rating, the Department Year 2000 Progress Rating and the Department Year 2000 Budget Rating.

5.3.1 The Year 2000 Project Progress Rating and Department Year 2000 Progress Rating

The first Year 2000 Project Progress Rating will be formed by evaluating the six deliverables of the Detailed Planning Phase (see Section 4 for a complete description of the deliverables). All subsequent Year 2000 Project Progress Ratings are formed by evaluating the Monthly Project Reports (see Section 5.1 for a description of these reports) as described in Table 5.3-1 Interpretation of Progress Ratings below.

Individual Year 2000 Project Progress Ratings and Department Year 2000 Progress Ratings are communicated on a scale between one and five. One being the lowest rating and five being the highest rating. Both Project and Department Year 2000 Progress ratings may be interpreted as follows:

 

Progress Rating	Interpretation of Rating
Five (5)	No Problems or Project performing to plan or ahead of schedule.
Four (4)	Project is not performing to plan. Project Management is aware of problems and problems are under active planned control.
Three (3)	Project is not performing to plan. Project management is aware of problems and has plans to address and resolve them.
Two (2)	Project is not performing to plan. Project Management is aware of problems but solutions are not yet defined or planned.
One (1)	Project is not performing to plan. Project Management is not aware of problems or their impact to project success.

Table 5.3-1 Interpretation of Progress Ratings

The Department Year 2000 Progress Rating is a weighted average of individual Year 2000 Project Progress Ratings. The point value assigned to each project is weighted by the original estimated total cost of the project as reported in the State of Colorado Year 2000 Cost Estimates Volume I relative to other department projects. The Department Year 2000 Progress Rating will be distributed to the Colorado Year 2000 Project Executive Oversight Committee, the members of the Commission on Information Management (IMC) and published on the State of Colorado Year 2000 WebSite on a monthly basis. A sample Department Year 2000 Progress Rating calculation is shown below in Table 5.3-2 Department Year 2000 Progress Rating Example Calculation.

Project Name   Column A	Project Progress Rating Column B	Estimated Project Cost Column C	Percentage of the Total Dept. Year 2000 Project Cost Column D	Weighted Point Value Column B times Column D
Project 1	5	$ 1,000,000	.435	2.15
Project 2	3	$ 1,000,000	.435	1.30
Project 3	3	$ 50,000	.020	0.06
Project 4	1	$ 250,000	.110	0.11
Department Year 2000 Progress Rating	n/a	$ 2,300,000	1.000	3.67

Table 5.3-2 Department Year 2000 Progress Rating Example Calculation

5.3.2 Department Year 2000 Budget Rating.

The Department Year 2000 Budget Rating is formed by evaluating the quarterly reports submitted on a department wide basis by the department Year 2000 Coordinator. (See Section 5.2 for a discussion and example of this quarterly report.) The rating communicates how the department is performing within the budget for department wide Year 2000 efforts. These budgets were created by the departments during the assessment phase of the Year 2000 effort. Ratings are communicated on a scale between one and five. One being the lowest rating and five being the highest rating. Table 5.3-3- Interpretation of Department Year 2000 Budget Rating shows how the rating is interpreted.

Department Year 2000 Budget Rating	Interpretation of Rating
Five (5)	Budget Variance less than or equal to 10%.
Four (4)	Budget Variance 11-20%.
Three (3)	Budget Variance 21- 30%.
Two (2)	Budget Variance 31- 40%.
One (1)	Budget Variance greater than 40%.

Table 5.3-3 Interpretation of Department Year 2000 Budget Rating

6. Compliance Verification

The development of compliance verification is in progress and will be published at a later date.

.

Appendix A: Project Inventory Document

Figure A-1: Project Inventory Sample Document illustrates a project inventory document

 

Figure A -1: Project Inventory Sample Document

 

Appendix B: Sample Work Plan

Appendix C: Staffing Plan

Appendix D: Risk and Issues Management Plan

The following is an example of a Risk and Issues Management Log.

Risk/Issue Tracking Number	Risk or Issue Description	Project Impact Fatal, Critical Manageable Marginal	Solution	Status Open No Action Planned Being Implemented Complete	Responsible
1	Need Natural upgrade prior to changing SQL in NATURAL	Critical	Obtain Beta s/w for test	Planned	Dick
2	Client availability for Acceptance Test	Critical Fatal after 11-97	Get full time client person assigned to team	Being Implemented	Ron
3	Five new office/cubes for team contractors scheduled for start 10-97	Manageable	Move new members of team to rental space 9-30	Planned	Alice

 

 

 

 

 

Appendix E: Testing Guidelines and Scenarios for Year 2000 Conversion

Testing against the century-compliance criteria falls into the follow three categories:

1. General. Some aspects of century compliance are independent of technology and application domain. For example, January 1, 2000 follows December 31, 1999, for all hardware and software.
2. Technology-specific. Some aspects of century compliance depend on the technology and the behaviors and features of that technology. For example, not all software performs all the date manipulations listed in Figure E-1.
3. Domain-specific. Some aspects of century compliance depend on the requirements of a specific application. For example, the valid ranges for dates to be tested can vary with each application.

Figure E-1: High-Level Guidelines for Test Cases in Year 2000 Test Procedures, provides considerations to use in designing test procedures. Testing should be organized by category to permit reusing test procedures among different applications.

Category	Sub-category	Guidelines
General	Current date	Direct set, power-up roll-over Re-initialize from cold start Full date ranges
	Calendar accuracy	Days of week in 2000 and 2001 Leap year in 2000 366 days in 2000
	Century ambiguity	High-risk values (1999-12-31, 1900-01-01,2000-01-01, 2000-02-29)
Technology-specific	Current date	Power-down continuity System date versus current date
	Date representation	Overflow of base-and-offset representation Standards for Gregorian formats Century capability in storage and interfaces
	Date manipulation	Date arithmetic Conversion between representations Sorting, searching, indexing Century designation available in storage and interfaces
Domain-specific	Century ambiguity	Accuracy in inferring century for each field in storage, user interface and other interfaces
	Date representation	Industry standards and contract requirements Human-factors requirements Design and coding standards
	Date manipulation	Access to archived data Manipulation of archived data Extended semantics

Figure E-1: High-Level Guidelines for Test Cases in Year 2000 Test Procedures

 

 

Appendix F: Monthly Project Status Reporting

The following blank form is used for entering project base estimates for Year 2000 project reporting.

The following form is used to report monthly actuals by project and estimates to complete by project. Report one project per line on the report.

Appendix G: Quarterly Department Financial Reporting

The following blank form is used for quarterly Year 2000 department financial reporting.

The following is a sample of a department quarterly Year 2000 financial reporting for the period ended December 31, 1997. Actual expenditures are reported through December and estimates are provided for the remaining quarters for the department.