SM-12 - PROJECT MANAGEMENT ACTIVITIES - D R A F T REVISION Purpose. This Defense Finance and Accounting Service (DFAS) Financial Systems Organization (FSO) policy establishes Software Project Management (PM) responsibilities and processes for the modernization or modification of Automated Information Systems (AISs). It specifically addresses a standard set of processes for estimation, planning, and tracking and oversight activities. This policy outlines the goals of the Software Engineering Institute’s Capability Maturity Model for key process areas of Software Project Planning, Software Project Tracking and Oversight, and Integrated Software Management. Scope. The FSO is defined as FSO Headquarters and all Financial Systems Activities and Directorates for Software Engineering. This policy applies to all AISs of the organization. Goals. Software estimates are documented for use in planning and tracking the software project. Software project activities and commitments are planned and documented. Affected groups and individuals agree to their commitments related to the software project. Actual results and progress are tracked against the software plans. Corrective actions are taken and managed to closure when actual results and progress deviate significantly from the software plans. Changes to software commitments are agreed to by the affected groups and individuals. The project’s defined software process is a tailored version of the organization’s standard software process. The project is planned and managed according to the project’s defined software process. Policy Statements: 1. Each Financial Systems Activity shall implement a Project Management program for each AIS within its purview. This program will use the framework established within the applicable scenario (e.g., SMS) to provide management control and oversight of the estimation, planning, and tracking and oversight functions. 2. System requirements allocated to software are used as the basis for planning the software project. The software engineering group uses these allocated requirements as the basis for software plans, work products, and activities. The allocated requirements are the basis for the software development plan (SDP) and the basis for developing the software requirements. 3. The software planning process shall result in the project’s SDP. This process includes steps to estimate the size of the software work products (i.e., configuration items), estimate the effort and cost, identify critical computer resource requirements, document critical dependencies and critical paths, produce a schedule, identify and assess software risks, and negotiate commitments. Iterating through these steps may be necessary to establish the SDP for the software release. The SDP shall provide the basis for performing, managing, and tracking the software project/release's activities and address the commitments to the software project's customer according to the resources, constraints, and capabilities for the software project/release. 4. Affected groups review the software project’s software size estimates, effort and cost estimates, schedules, and other commitments. These affected groups may include software engineering (to include subgroups such as software design), software estimating, system engineering, system test, software quality assurance, software configuration management, contract management, and documentation support. 5. The software project’s commitments are negotiated between the project manager, the project software manager, and the other software managers. Involvement of other engineering groups (such as system engineering, hardware engineering, and system test) in the software activities is negotiated with these groups and is documented. Changes to software commitments are made with the involvement and agreement of the affected groups. Senior management reviews all new and changed software project commitments made to individuals and groups external to the organization. 6. The project manager is kept informed of the software project’s status and issues. Corrective actions are taken when the software plan is not being achieved, either by adjusting performance or by adjusting the plans. 7. Each project documents its defined software process by tailoring the organization’s standard software process. The project’s deviations from the organization’s standard software process are documented and approved. Each project performs its software activities in accordance with the project’s defined software process. 8. Each project collects and stores appropriate project measurement data in the organization’s software process database (see FSO Policy SM-14, Software Metrics Strategic Action Plan). The software process database shall be used as a source of data to estimate, plan, track and replan the software project. A group independent of the software engineering group shall review the procedures for estimating the size of the software work products and provide guidance in using historical data from the organization’s software process database. 9. Technical and management lessons learned are documented and provided to FSO HQ for inclusion in the organization’s process asset library. The technical and management lessons learned from monitoring the activities of other projects in the organization shall be systematically reviewed and used to estimate, plan, track, and replan the software project. References. 1. SEI Capability Maturity Model 2. FSO Policy SM-14, Software Metrics Strategic Action Plan 3. FSO Policy SM-21, Organization Process Focus and Definition, Attachments 4 and 5 Point of Contact. If you have questions or comments, the point of contact for this policy is the FSO Systems Management Directorate, DFAS-FSO/SS, at DSN 699-5927 or commercial 317-510-5927, or by fax at DSN 699-5827 or commercial 317-510-5827.