|Project Planning (PP)||
|The CMMi easy button concept and disclaimer
Disclaimer: The opinions expressed here are the authors
and do not express a position on the subject from the
Software Engineering Institute (SEI) or any organization
or SEI Partner affiliated with the SEI.
The concept of The CMMi easy button is to be able to
jump start SQA software professionals in establishing an
effective Software process Improvement (SPI) framework that is based on CMMi theories and best practices.
CMMI, CMM, and Capability Maturity Model are registered
in the U.S. Patent and Trademark Office.
CMM Integration, SCAMPI, and IDEAL are service marks of
Carnegie Mellon University.
|Causal Analysis and Resolution (CAR)||Configuration Management (CM)||Decision Analysis and Resolution (DAR)|
|Integrated Project Management +IPPD (IPM+IPPD)||Measurement and Analysis (MA)||Organizational Innovation and Deployment (OID)|
|Organizational Process Definition +IPPD (OPD+IPPD)||Organizational Process Focus (OPF)||Organizational Process Performance (OPP)|
|Organizational Training (OT)||Product Integration (PI)||Project Monitoring and Control (PMC)|
|Project Planning (PP)||Process and Product Quality Assurance (PPQA)||Quantitative Project Management (QPM)|
|Requirements Development (RD)||Requirements Management (REQM)||Risk Management (RSKM)|
|Supplier Agreement Management (SAM)||Technical Solution (TS)||Validation (VAL)|
|Project Planning (PP) purpose and introductory notes|
|Specific Goals and Practices|
|Specific Goal 1 (SG 1) Establish Estimates (SP 1.*)|
|SP 1.1 Estimate the Scope of the Project||SP 1.2 Establish Estimates of Work Product and Task Attributes||SP 1.3 Define Project Lifecycle||SP 1.4 Determine Estimates of Effort and Cost|
|Specific Goal 2 (SG 2) Develop a Project Plan (SP 2.*)|
|SP 2.1 Establish the Budget and Schedule||SP 2.2 Identify Project Risks||SP 2.3 Plan for Data Management||SP 2.4 Plan for Project Resources|
|SP 2.5 Plan for Needed Knowledge and Skills||SP 2.6 Plan Stakeholder Involvement||SP 2.7 Establish the Project Plan||.|
|Specific Goal 3 (SG 3) Obtain Commitment to the Plan (SP 3.*)|
|SP 3.1 Review Plans That Affect the Project||SP 3.2 Reconcile Work and Resource Levels||SP 3.3 Obtain Plan Commitment||.|
|Generic Goals and Practices|
|Generic Goal 1 (GG 1) Achieve Specific Goals, Generic Practices (GP 1.*)|
|GP 1.1 Perform Specific Practices||.||.||.|
|Generic Goal 2 (GG 2) Institutionalize a Managed Process, Generic Practices (GP 2.*)|
|GP 2.1 Establish an Organizational Policy||GP 2.2 Plan the Process||GP 2.3 Provide Resources||GP 2.4 Assign Responsibility|
|GP 2.5 Train People||GP 2.6 Manage Configurations||GP 2.7 Identify and Involve Relevant Stakeholders||GP 2.8 Monitor and Control the Process|
|GP 2.9 Objectively Evaluate Adherence||GP 2.10 Review Status with Higher Level Management||.||.|
|Generic Goal 3 (GG 3) Institutionalize a Defined Process, Generic Practices (GP 3.*)|
|GP 3.1 Establish a Defined Process||GP 3.2 Collect Improvement Information||.||.|
|Generic Goal 4 (GG 4) Institutionalize a Quantitatively Managed Process, Generic Practices (GP 4.*)|
|GP 4.1 Establish Quantitative Objectives for the Process||GP 4.2 Stabilize Subprocess Performance||.||.|
|Generic Goal 5 (GG 5) Institutionalize an Optimizing Process, Generic Practices (GP 5.*)|
|GP 5.1 Ensure Continuous Process Improvement||GP 5.2 Correct Root Causes of Problems||.||.|
Project Planning (PP) lays out the goals of the project and the course the given project is expected to take in order to satisfy its goals. This planning activity includes scope and selection of the appropriate SDLC to fulfill the stated goals.
Estimating also forms a vital part of the planning process in order that appropriate resources (including Human) can be scheduled at the appropriate time in the projects life cycle.
This process is a prerequisite for Project Monitoring and Control (PMC) which checks the projects progress against its overall plan.
Project Planning (PP)
A Project Management Process Area at Maturity Level 2
The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.
The Project Planning process area involves the following:
Planning includes estimating the attributes of the work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analyzing project risks. Iterating through these activities may be necessary to establish the project plan. The project plan provides the basis for performing and controlling the project’s activities that address the commitments with the project’s customer.
The project plan will usually need to be revised as the project progresses to address changes in requirements and commitments, inaccurate estimates, corrective actions, and process changes. Specific practices describing both planning and replanning are contained in this process area.
The term “project plan” is used throughout the generic and specific practices in this process area to refer to the overall plan for controlling the project.
Related Process Areas
Refer to the Requirements Development process area for more information about developing requirements that define the product and product components. Product and product component requirements and changes to those requirements serve as a basis for planning and replanning.
Refer to the Requirements Management process area for more information about managing requirements needed for planning and replanning.
Refer to the Risk Management process area for more information about identifying and managing risks.
Refer to the Technical Solution process area for more information about transforming requirements into product and product component solutions.
Specific Practices by Goal
SG 1 Establish Estimates
Estimates of project planning parameters are established and maintained.
Project planning parameters include all information needed by the project to perform the necessary planning, organizing, staffing, directing, coordinating, reporting, and budgeting.
Estimates of planning parameters should have a sound basis to instill confidence that any plans based on these estimates are capable of supporting project objectives.
Factors that are typically considered when estimating these parameters include the following:
SP 1.1 Estimate the Scope of the Project
Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.
The WBS evolves with the project. Initially a top-level WBS can serve to structure the initial estimating. The development of a WBS divides the overall project into an interconnected set of manageable components. Typically, the WBS is a product oriented structure that provides a scheme for identifying and organizing the logical units of work to be managed, which are called “work packages.” The WBS provides a reference and organizational mechanism for assigning effort, schedule, and responsibility and is used as the underlying framework to plan, organize, and control the work done on the project. Some projects use the term “contract WBS” to refer to the portion of the WBS placed under contract (possibly the entire WBS). Not all projects have a contract WBS (e.g., internally funded development).
Typical Work Products
The WBS provides a scheme for organizing the project’s work around the product and product components that the work supports. The WBS should permit the identification of the following items:
The top-level WBS is intended to help in gauging the project work effort in terms of tasks and organizational roles and responsibilities. The amount of detail in the WBS at this more detailed level helps in developing realistic schedules, thereby minimizing the need for management reserve.
Subpractice 3: Identify product or product components that will be externally acquired.
Refer to the Supplier Agreement Management process area for more information about acquiring products from sources external to the project.
Subpractice 4: Identify work products that will be reused.
SP 1.2 Establish Estimates of Work Product and Task Attributes
Establish and maintain estimates of the attributes of the work products and tasks.
Size is the primary input to many models used to estimate effort, cost, and schedule. The models can also be based on inputs such as connectivity, complexity, and structure.
Examples of types of work products for which size estimates are made include the following:
Typical Work Products
The technical approach defines a top-level strategy for development of the product. It includes decisions on architectural features, such as distributed or client/server; state-of-the-art or established technologies to be applied, such as robotics, composite materials, or artificial intelligence; and breadth of the functionality expected in the final products, such as safety, security, and ergonomics.
Subpractice 2: Use appropriate methods to determine the attributes of the work products and tasks that will be used to estimate the resource requirements.
Methods for determining size and complexity should be based on validated models or historical data.
The methods for determining attributes evolve as our understanding of the relationship of product characteristics to attributes increases.
Examples of current methods include the following:
SP 1.3 Define Project Lifecycle
Define the project lifecycle phases on which to scope the planning effort.
The determination of a project’s lifecycle phases provides for planned periods of evaluation and decision making. These are normally defined to support logical decision points at which significant commitments are made concerning resources and technical approach. Such points provide planned events at which project course corrections and determinations of future scope and cost can be made.
The project lifecycle phases need to be defined depending on the scope of requirements, the estimates for project resources, and the nature of the project. Larger projects may contain multiple phases, such as concept exploration, development, production, operations, and disposal. Within these phases, subphases may be needed. A development phase may include subphases such as requirements analysis, design, fabrication, integration, and verification. The determination of project phases typically includes selection and refinement of one or more development models to address interdependencies and appropriate sequencing of the activities in the phases.
Depending on the strategy for development, there may be intermediate phases for the creation of prototypes, increments of capability, or spiral model cycles.
Understanding the project lifecycle is crucial in determining the scope of the planning effort and the timing of the initial planning, as well as the timing and criteria (critical milestones) for replanning.
Typical Work Products
Estimate the project effort and cost for the work products and tasks based on estimation rationale.
Estimates of effort and cost are generally based on the results of analysis using models or historical data applied to size, activities, and other planning parameters. Confidence in these estimates is based on the rationale for the selected model and the nature of the data. There may be occasions when the available historical data does not apply, such as where efforts are unprecedented or where the type of task does not fit available models. An effort is unprecedented (to some degree) if a similar product or component has never been built. An effort may also be unprecedented if the development group has never built such a product or component.
Unprecedented efforts are more risky, require more research to develop reasonable bases of estimate, and require more management reserve. The uniqueness of the project must be documented when using these models to ensure a common understanding of any assumptions made in the initial planning stages.
Typical Work Products
Many parametric models have been developed to aid in estimating cost and schedule. The use of these models as the sole source of estimation is not recommended because these models are based on historical project data that may or may not be pertinent to your project. Multiple models and/or methods can be used to ensure a high level of confidence in the estimate.
Historical data include the cost, effort, and schedule data from previously executed projects, plus appropriate scaling data to account for differing sizes and complexity.
Subpractice 2: Include supporting infrastructure needs when estimating effort and cost.
The supporting infrastructure includes resources needed from a development and sustainment perspective for the product.
Consider the infrastructure resource needs in the development environment, the test environment, the production environment, the target environment, or any appropriate combination of these when estimating effort and cost.
Examples of infrastructure resources include the following:
Effort and cost inputs used for estimating typically include the following:
A project plan is established and maintained as the basis for managing the project.
A project plan is a formal, approved document used to manage and control the execution of the project. It is based on the project requirements and the established estimates.
The project plan should consider all phases of the project lifecycle. Project planning should ensure that all plans affecting the project are consistent with the overall project plan.
SP 2.1 Establish the Budget and Schedule
Establish and maintain the project’s budget and schedule.
The project’s budget and schedule are based on the developed estimates and ensure that budget allocation, task complexity, and task dependencies are appropriately addressed.
Event-driven, resource-limited schedules have proven to be effective in dealing with project risk. Identifying accomplishments to be demonstrated before initiation of the event provides some flexibility in the timing of the event, a common understanding of what is expected, a better vision of the state of the project, and a more accurate status of the project’s tasks.
Typical Work Products
Milestones are often imposed to ensure completion of certain deliverables by the milestone. Milestones can be event based or calendar based. If calendar based, once milestone dates have been agreed on, it is often very difficult to change them.
Subpractice 2: Identify schedule assumptions.
When schedules are initially developed, it is common to make assumptions about the duration of certain activities. These assumptions are frequently made on items for which little if any estimation data is available. Identifying these assumptions provides insight into the level of confidence (uncertainties) in the overall schedule.
Subpractice 3: Identify constraints.
Factors that limit the flexibility of management options need to be identified as early as possible. The examination of the attributes of the work products and tasks often will bring these issues to the surface. Such attributes can include task duration, resources, inputs, and outputs.
Subpractice 4: Identify task dependencies.
Typically, the tasks for a project can be accomplished in some ordered sequence that will minimize the duration of the project. This involves the identification of predecessor and successor tasks to determine the optimal ordering.
Examples of tools that can help determine an optimal ordering of task activities include the following:
Establishing and maintaining the project’s budget and schedule typically includes the following:
Criteria are established for determining what constitutes a significant deviation from the project plan. A basis for gauging issues and problems is necessary to determine when a corrective action should be taken. The corrective actions may require replanning, which may include revising the original plan, establishing new agreements, or including mitigation activities within the current plan.
SP 2.2 Identify Project Risks
Identify and analyze project risks.
Refer to the Risk Management process area for more information about risk management activities.
Refer to the Monitor Project Risks specific practice in the Project Monitoring and Control process area for more information about risk monitoring activities.
Risks are identified or discovered and analyzed to support project planning. This specific practice should be extended to all the plans that affect the project to ensure that the appropriate interfacing is taking place between all relevant stakeholders on identified risks. Project planning risk identification and analysis typically include the following:
The identification of risks involves the identification of potential issues, hazards, threats, vulnerabilities, and so on that could negatively affect work efforts and plans. Risks must be identified and described in an understandable way before they can be analyzed. When identifying risks, it is a good idea to use a standard method for defining risks. Risk identification and analysis tools can be used to help identify possible problems.
Examples of risk identification and analysis tools include the following:
Subpractice 3: Review and obtain agreement with relevant stakeholders on the completeness and correctness of the documented risks.
Subpractice 4: Revise the risks as appropriate.
Examples of when identified risks may need to be revised include the following:
Plan for the management of project data.
When integrated teams are formed, project data includes data developed and used solely within a particular team as well as data applicable across integrated team boundaries, if there are multiple integrated teams.
Data are the various forms of documentation required to support a program in all of its areas (e.g., administration, engineering, configuration management, finance, logistics, quality, safety, manufacturing, and procurement). The data can take any form (e.g., reports, manuals, notebooks, charts, drawings, specifications, files, or correspondence). The data may exist in any medium (e.g., printed or drawn on various materials, photographs, electronic, or multimedia). Data may be deliverable (e.g., items identified by a program’s contract data requirements) or data may be nondeliverable (e.g., informal data, trade studies and analyses, internal meeting minutes, internal design review documentation, lessons learned, and action items). Distribution can take many forms, including electronic transmission.
The data requirements for the project should be established for both the data items to be created and their content and form, based on a common or standard set of data requirements. Uniform content and format requirements for data items facilitate understanding of data content and help with consistent management of the data resources.
The reason for collecting each document should be clear. This task includes the analysis and verification of project deliverables and nondeliverables, contract and noncontract data requirements, and customer-supplied data. Often, data is collected with no clear understanding of how it will be used. Data is costly and should be collected only when needed.
Typical Work Products
Not everyone will have the need or clearance necessary to access the project data. Procedures must be established to identify who has access to what data as well as when they have access to the data.
Subpractice 2: Establish a mechanism to archive data and to access archived data.
Accessed information should be in an understandable form (e.g., electronic or computer output from a database) or represented as originally generated.
Subpractice 3: Determine the project data to be identified, collected, and distributed.
SP 2.4 Plan for Project Resources
Plan for necessary resources to perform the project.
When integrated teams are formed, planning for project resources should consider staffing of the integrated teams.
Defining project resources (labor, machinery/equipment, materials, and methods) and quantities needed to perform project activities builds on the initial estimates and provides additional information that can be applied to expand the WBS used to manage the project.
The top-level WBS developed earlier as an estimation mechanism is typically expanded by decomposing these top levels into work packages that represent singular work units that can be separately assigned, performed, and tracked. This subdivision is done to distribute management responsibility and provide better management control. Each work package or work product in the WBS should be assigned a unique identifier (e.g., number) to permit tracking. A WBS can be based on requirements, activities, work products, or a combination of these items. A dictionary that describes the work for each work package in the WBS should accompany the work breakdown structure.
Typical Work Products
The processes used to manage a project must be identified, defined, and coordinated with all the relevant stakeholders to ensure efficient operations during project execution.
Subpractice 2: Determine staffing requirements.
The staffing of a project depends on the decomposition of the project requirements into tasks, roles, and responsibilities for accomplishing the project requirements as laid out within the work packages of the WBS.
Staffing requirements must consider the knowledge and skills required for each of the identified positions, as defined in the Plan for Needed Knowledge and Skills specific practice.
Subpractice 3: Determine facilities, equipment, and component requirements.
Most projects are unique in some sense and require some set of unique assets to accomplish the objectives of the project. The determination and acquisition of these assets in a timely manner are crucial to project success.
Lead-time items need to be identified early to determine how they will be addressed. Even when the required assets are not unique, compiling a list of all of the facilities, equipment, and parts (e.g., number of computers for the personnel working on the project, software applications, and office space) provides insight into aspects of the scope of an effort that are often overlooked.
SP 2.5 Plan for Needed Knowledge and Skills
Plan for knowledge and skills needed to perform the project.
Refer to the Organizational Training process area for more information about knowledge and skills information to be incorporated into the project plan.
Knowledge delivery to projects involves both training of project personnel and acquisition of knowledge from outside sources.
Staffing requirements are dependent on the knowledge and skills available to support the execution of the project.
Typical Work Products
Subpractice 2: Assess the knowledge and skills available.
Subpractice 3: Select mechanisms for providing needed knowledge and skills.
Example mechanisms include the following:
Subpractice 4: Incorporate selected mechanisms into the project plan.
SP 2.6 Plan Stakeholder Involvement
Plan the involvement of identified stakeholders.
When integrated teams are formed, stakeholder involvement should be planned down to the integrated team level.
Stakeholders are identified from all phases of the project lifecycle by identifying the type of people and functions needing representation in the project and describing their relevance and the degree of interaction for specific project activities. A two-dimensional matrix with stakeholders along one axis and project activities along the other axis is a convenient format for accomplishing this identification. Relevance of the stakeholder to the activity in a particular project phase and the amount of interaction expected would be shown at the intersection of the project phase activity axis and the stakeholder axis.
For the inputs of stakeholders to be useful, careful selection of relevant stakeholders is necessary. For each major activity, identify the stakeholders who are affected by the activity and those who have expertise that is needed to conduct the activity. This list of relevant stakeholders will probably change as the project moves through the phases of the project lifecycle. It is important, however, to ensure that relevant stakeholders in the latter phases of the lifecycle have early input to requirements and design decisions that affect them.
Examples of the type of material that should be included in a plan for stakeholder interaction include the following:
Typical Work Products
Establish and maintain the overall project plan content.
A documented plan that addresses all relevant planning items is necessary to achieve the mutual understanding, commitment, and performance of individuals, groups, and organizations that must execute or support the plans. The plan generated for the project defines all aspects of the effort, tying together in a logical manner: project lifecycle considerations; technical and management tasks; budgets and schedules; milestones; data management, risk identification, resource and skill requirements; and stakeholder identification and interaction. Infrastructure descriptions include responsibility and authority relationships for project staff, management, and support organizations.
For Software Engineering
For software, the planning document is often referred to as one of the following:
For hardware, the planning document is often referred to as a hardware development plan. Development activities in preparation for production may be included in the hardware development plan or defined in a separate production plan.
Examples of plans that have been used in the U.S. Department of Defense community include the following:
Commitments to the project plan are established and maintained.
To be effective, plans require commitment by those responsible for implementing and supporting the plan.
SP 3.1 Review Plans That Affect the Project
Review all plans that affect the project to understand project commitments.
When integrated teams are formed, their integrated work plans are among the plans to review.
Plans developed within other process areas will typically contain information similar to that called for in the overall project plan. These plans may provide additional detailed guidance and should be compatible with and support the overall project plan to indicate who has the authority, responsibility, accountability, and control. All plans that affect the project should be reviewed to ensure a common understanding of the scope, objectives, roles, and relationships that are required for the project to be successful. Many of these plans are described by the Plan the Process generic practice in each of the process areas.
Typical Work Products
Reconcile the project plan to reflect available and estimated resources.
When integrated teams are formed, special attention should be paid to resource commitments in circumstances of distributed integrated teams and when people are on multiple integrated teams in one or more projects.
To establish a project that is feasible, obtain commitment from relevant stakeholders and reconcile any differences between the estimates and the available resources. Reconciliation is typically accomplished by lowering or deferring technical performance requirements, negotiating more resources, finding ways to increase productivity, outsourcing, adjusting the staff skill mix, or revising all plans that affect the project or schedules.
Typical Work Products
Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.
When integrated teams are formed, the integrated team plans should have buy-in from the team members, the interfacing teams, the project, and the process owners of the standard processes that the team has selected for tailored application.
Obtaining commitment involves interaction among all relevant stakeholders both internal and external to the project. The individual or group making a commitment should have confidence that the work can be performed within cost, schedule, and performance constraints. Often, a provisional commitment is adequate to allow the effort to begin and to permit research to be performed to increase confidence to the appropriate level needed to obtain a full commitment.
Typical Work Products
The WBS can be used as a checklist for ensuring that commitments are obtained for all tasks.
The plan for stakeholder interaction should identify all parties from whom commitment should be obtained.
Subpractice 2: Document all organizational commitments, both full and provisional, ensuring appropriate level of signatories.
Commitments must be documented to ensure a consistent mutual understanding as well as for tracking and maintenance. Provisional commitments should be accompanied by a description of the risks associated with the relationship.
Subpractice 3: Review internal commitments with senior management as appropriate.
Subpractice 4: Review external commitments with senior management as appropriate.
Management may have the necessary insight and authority to reduce risks associated with external commitments.
Subpractice 5: Identify commitments on interfaces between elements in the project, and with other projects and organizational units so that they can be monitored.
Well-defined interface specifications form the basis for commitments.
Generic Practices by Goal
GG 1 Achieve Specific Goals
The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.
GP 1.1 Perform Specific Practices
Perform the specific practices of the project planning process to develop work products and provide services to achieve the specific goals of the process area.
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.
GP 2.1 Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the project planning process.
This policy establishes organizational expectations for estimating the planning parameters, making internal and external commitments, and developing the plan for managing the project.
GP 2.2 Plan the Process
Establish and maintain the plan for performing the project planning process.
Refer to Table 6.2 on page 95 in Generic Goals and Generic Practices for more information about the relationship between generic practice 2.2 and the Project Planning process area.
GP 2.3 Provide Resources
Provide adequate resources for performing the project planning process, developing the work products, and providing the services of the process.
Special expertise, equipment, and facilities in project planning may be required. Special expertise in project planning may include the following:
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the project planning process.
GP 2.5 Train People
Train the people performing or supporting the project planning process as needed.
Examples of training topics include the following:
Place designated work products of the project planning process under appropriate levels of control.
Examples of work products placed under control include the following:
Identify and involve the relevant stakeholders of the project planning process as planned.
Refer to Table 6.2 on page 95 in Generic Goals and Generic Practices for more information about the relationship between generic practice 2.7 and the Plan Stakeholder Involvement practice in the Project Planning process area.
Examples of activities for stakeholder involvement include the following:
Monitor and control the project planning process against the plan for performing the process and take appropriate corrective action.
Examples of measures and work products used in monitoring and controlling include the following:
Objectively evaluate adherence of the project planning process against its process description, standards, and procedures, and address noncompliance.
Examples of activities reviewed include the following:
Review the activities, status, and results of the project planning process with higher level management and resolve issues.
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.
This generic goal's appearance here reflects its location in the continuous representation.
GP 3.1 Establish a Defined Process
Establish and maintain the description of a defined project planning process.
GP 3.2 Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the project planning process to support the future use and improvement of the organization’s processes and process assets.
Examples of work products, measures, measurement results, and improvement information include the following:
The process is institutionalized as a quantitatively managed process.
GP 4.1 Establish Quantitative Objectives for the Process
Establish and maintain quantitative objectives for the project planning process, which address quality and process performance, based on customer needs and business objectives.
GP 4.2 Stabilize Subprocess Performance
Stabilize the performance of one or more subprocesses to determine the ability of the project planning process to achieve the established quantitative quality and process-performance objectives.
GG 5 Institutionalize an Optimizing Process
The process is institutionalized as an optimizing process.
GP 5.1 Ensure Continuous Process Improvement
Ensure continuous improvement of the project planning process in fulfilling the relevant business objectives of the organization.
GP 5.2 Correct Root Causes of Problems
Identify and correct the root causes of defects and other problems in the project planning process.
Software-Quality-Assurance.org is an independent Web Site that presents information about CMMi and Software Quality Assurance.
No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-