Information Technology Project Management
This document is an HTML formatted version of a printed document. The printed document may contain agency comments, charts, photographs, appendices, footnotes and page numbers which may not be reproduced in this electronic version. If you require a printed version of this document contact the United States Securities and Exchange Commission, Office of Inspector General, Mail Stop 11-7, 450 Fifth Street N.W., Washington, D.C. 20549 or call (202) 942-4460.
INFORMATION TECHNOLOGY PROJECT MANAGEMENT
Audit No. 337
January 22, 2002
EXECUTIVE SUMMARY
The Office of Inspector General conducted an audit of project management methods and practices performed by the Commission's Office of Information Technology (OIT). We evaluated whether OIT's management of information technology (IT) projects was adequate, and in compliance with applicable laws and regulations. We found that project management methods and practices implemented by OIT were generally adequate, and in compliance with most aspects of recently enacted laws and regulations.
Although OIT has made significant progress in defining, documenting, and approving a Project Management Methodology and System Development Life Cycle Model, OIT could further strengthen its project management methods and practices by:
1. Establishing an effective support structure and enabling processes for project management,
2. Establishing effective tracking and oversight controls for monitoring contractor performance and projects managed by program area personnel, and
3. Establishing and using performance-based acquisition analysis evaluation methods, techniques, and criteria to comply with the Federal Acquisition Streamlining Act.
We are recommending several improvements, including: testing the operational effectiveness of approved project management policies and procedures before mandating their use; establishing a project management regulation (i.e., an SECR) for program area managed projects; establishing tracking and oversight controls for monitoring contractor performance; and implementing a cost-effective performance-based acquisition analysis process that complies with the Federal Acquisition Streamlining Act of 1994.
OIT's comments on the draft report are attached. We modified the report as appropriate to reflect their comments.
SCOPE AND OBJECTIVES
Our audit objective was to evaluate whether OIT's management of projects was adequate and in compliance with applicable laws and regulations. We focused on three areas in evaluating OIT's project management practices and methods: management oversight; project management techniques and software; and project management planning, approval, and monitoring. During the audit, among other procedures, we:
- Reviewed SEC project management policy and procedure documentation and reconciled them to applicable laws and implementing instructions governing the management of information technology projects;
- Reconciled OIT's $44 million FY 2001 information technology budget to its documented inventory of funded and unfunded projects;
- Evaluated the financial management system used by OIT to manage and control the SEC's information technology project costs;
- Interviewed senior OIT staff and project managers;
- Met with Program Office representatives who performed project management functions;
- Evaluated implementation of OIT's project management methods and practices;
- Performed limited reviews and evaluations of the completeness of project management files for 8 projects costing $8.1 million (see Appendix A for a complete listing of the projects selected for review); and
- Reviewed contracts and other relevant contract management documents for the projects included in the scope of the audit. However, we curtailed our work in this area. We plan to evaluate OIT's contract management processes and controls in a separate audit.
We performed our audit between April 2001 and September 2001, in accordance with generally accepted government auditing standards. We applied recently issued Office of Management and Budget (OMB) guidance and instructions to evaluate compliance with statutes. We also used the OMB guidance to evaluate whether OIT's planned improvements to its project management methods and practices were in alignment with legislative mandates governing project management.
BACKGROUND
LEGISLATIVE MANDATES
Enactment of the Clinger-Cohen Act of 1996 (Public Law 104-106), Federal Acquisition Streamlining Act of 1994 (Public Law 103-355), and Government Performance and Results Act (GPRA) of 1993 (Public Law 103-62) mandate that Federal agencies improve their information technology life-cycle management processes, methods, and practices.
Federal guidance and instructions that agencies are to follow in implementing the legislative mandates are contained in:
- Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources, dated November 30, 2000.
- OMB's Capital Programming Guide Supplement to OMB Circular A-11, Part 3, Planning, Budgeting, and Acquisition of Capital Assets, dated July 22, 1997.
Specifically, agencies are to manage information technology projects by:
- Establishing clear lines of authority, responsibility, and accountability for managing the project,
- Establishing thresholds for cost, schedule, and performance goals,
- Selecting efficient types of contracts and pricing mechanisms that provide incentives to contractors so that risks are appropriately allocated between the contractor and the Government,
- Monitoring project cost, schedule, and performance goals using an "earned value" management system versus using a "spend comparison" management system, and
- Establishing and implementing a performance-based project management information system that provides timely and useful cost, schedule, and performance information that facilitates timely and informed project management decisions.
Agencies have flexibility in how they manage information technology projects; however, they are to establish project management methods, practices, and procedures that comply with existing statutes and implementing instructions for achieving cost, schedule, and performance goals.
Appendix B contains a more detailed description of the legislative requirements related to project management. Appendix C contains OIT's criteria for defining a project that requires special management attention. Appendix D describes the fundamental differences between project management processes and system development life cycle processes.
AUDIT RESULTS
Although OIT has made significant progress in defining, documenting, and approving a Project Management Methodology (PMM) and System Development Life Cycle Model (SDLC), OIT could further strengthen its project management methods and practices to comply with applicable laws, implementing instructions, and regulations by:
- Establishing an effective support structure and enabling processes for project management,
- Establishing effective tracking and oversight controls for monitoring program area managed projects and contractor performance, and
- Establishing performance-based acquisition analysis methods, techniques, and evaluation criteria to comply with the Federal Acquisition Streamlining Act.
PROJECT MANAGEMENT IMPROVEMENTS
Over the past 14 months, OIT has made significant progress to bring its project management operations into compliance with OMB instructions for implementing recently enacted legislative mandates that govern the management of information technology (IT) projects and acquisitions. OIT's accomplishments in establishing a defined project management methodology, and OIT's planned and ongoing initiatives to standardize the methods and procedures that project managers use to manage the life cycle phases of IT projects are discussed below.
Envisioned Project Management Environment
Senior OIT management has recognized the need to obtain contractor support to fully implement a well defined, disciplined, structured, and consistent project management support capability. In April 2001, OIT's Office of Planning and Project Management (OPPM) received approval to initiate a $500,000 three-phased project management study. OIT plans to obtain consulting services available under the General Services Administration's Management, Organizational and Business Improvement Services (GSA-MOBIS) Federal Supply Schedule contract.
Our review of the draft statement of work and discussions with senior OIT management indicated that the study is intended to obtain recommendations on how to best establish and implement an effective Project Management Office (PMO) within OIT. According to the Assistant Director, OPPM, the study will:
- Analyze OIT's current project planning, tracking and control procedures, data and reporting requirements, program monitoring capabilities, and skill sets to identify performance gaps. This baseline analysis will provide the basis for developing an implementation strategy for an integrated and effective project management methodology (Phase 1),
- Establish a project management training program that will introduce the PMM to the organization, present the processes and practices of the approved PMM, and assist the organization in implementing proven project management practices in a consistent manner (Phase 2),
- Establish a strategy for implementing a more comprehensive PMO to include maintaining the project management methodology, assisting the organization in the adoption and execution of the methodology, monitoring and analyzing projects at the enterprise level, and producing reports and other required management information (Phase 3).
Our Office plans to monitor the planned actions OIT will take to implement the PMO recommendations provided under the $500,000 GSA-MOBIS consulting services contract.
Project Management Methodology
The OPPM within OIT is responsible for managing information technology projects approved by the Information Technology Capital Planning Committee (ITCPC). OPPM also provides project management support for infrastructure projects initiated by OIT. OPPM utilizes a matrix organization to manage IT projects. As such, teams comprised of contractors and personnel from various offices within OIT provide technical and operational support to project managers throughout the life cycle of a project.
Project managers are primarily responsible for managing the cost, schedule, and performance goals of projects assigned to them in accordance with OIT's Project Management Methodology (PMM). The PMM follows a nine-phased System Development Life Cycle (SDLC) model. The phases are initiation, requirement definition, analysis, design, development, testing, training, implementation/deployment, and acceptance/closeout.
OIT project managers focus their project management activities on managing and monitoring the performance of contractors in meeting deliverable schedules outlined in task orders and statements of work. To effectively manage a project throughout its life cycle, project managers use Microsoft Project to breakdown their work so that they can manage, coordinate, and schedule internal and external organizational support, such as contracting, configuration control, technical testing, deployment, and operations and maintenance issues. Appendix E defines the significance of the work breakdown structure in managing a project's cost, schedule, and performance goals.
Many procedures have been developed, approved, and implemented to attain a level 2 (i.e., repeatable) software development maturity level using the Software Engineering Institute's (SEI) Capability Maturity Model - Software (CMM-SW).1 The SEI's CMM-SW is comprised of five maturity levels. At maturity level 2, an organization has been elevated from ad hoc and chaotic management practices (level 1) to an organization with disciplined and sound software development management controls. Maturity level 5 organizations select and deploy incremental and innovative improvements that measurably improve the organization's software development processes and technologies.
Appendix F provides an overview of the SEI's CMM-SW methodology. Appendix G contains a listing of approved and pending policies and procedures, as of May 16, 2001 developed by OIT.
We concluded that when OIT fully implements and tests its PMM, the PMM would provide project managers a structured and standardized framework to achieve repeatable project management processes, and its project management operations should come into full compliance with applicable OMB instructions and legislative mandates governing project management.
Recommendation A
OIT should establish an action plan with milestones to test the operational effectiveness of OIT's current inventory of approved PMM policies and procedures.
OIT concurred with Recommendation A and stated that a list of issues identified by project managers and project team members prior to the commencement of the audit will be incorporated into an action plan for testing the operational effectiveness of adopted project management processes.
Review and Approval Mechanisms
During FY 2001, OIT initiated an improvement effort to strengthen and standardize its project management control processes. OIT established a board structure to review and approve the migration of a project to the next successive SDLC phase. The board structure is comprised of a Project Review Board (PRB), Organization Configuration Control Board (OCCB), and Technical Review Board (TRB). Appendix H describes the responsibilities of each board and depicts the required board approvals during the life cycle of a project.
During our audit, we determined that OIT could strengthen this component of its PMM by establishing standard board procedures and controls to validate whether project managers and contractors have complied with OIT's PMM requirements before approving the migration of a project to the next SDLC phase. This control feature could be implemented by requiring the PRB, OCCB, TRB, and Information Officers (IO) to establish formal checklists and sign-off procedures for approving the migration of a project to the next SDLC phase. OIT's Project Checklist document 22-25-017-001.0, dated July 17, 2001 provides a baseline for this control procedure. Board members should use these checklists as their primary focus during project milestone review and approval meetings.
Recommendation B
OIT should require OPPM to work with the PRB, OCCB, TRB, and IOs to establish and publish standardized project SDLC migration checklists and sign-off procedures and require the review and approval boards to use the checklists and sign-off procedures as their primary focus during project milestone reviews.
Recommendation C
OIT, in coordination with OED, should update its Project Management Methodology Policy (22-25-007-001(draft)) to incorporate the project management responsibilities incumbent upon Program Office IOs, or Office Heads for those offices not having an officially appointed IO.
OIT concurred with Recommendations B and C and stated that within the next six months checklists will be developed that define specific documents and sign-offs that must be prepared and completed as a project moves through its life cycle.
Manual and Automated Control Mechanisms
OIT also established manual and automated control mechanisms for managing project costs, assessing adherence to established project schedules, and evaluating achievement of the expected performance goals established for IT initiatives. These control mechanisms include the use of:
- Microsoft Project to manage project schedules for infrastructure related projects and contracted project development,
- Polytron Version Control System (PVCS) Tracker software to manage and track issues, problems, projects, workload, and support services;
- Weekly, bi-weekly, and monthly program/project reviews with the CIO and other senior OIT management,
- Quarterly ITCPC and Information Officer (IO) project status reports,
- Quarterly spending plans that compare project budgets to actual commitments;
- Year-end budget and execution variance analyses,
- Various Microsoft Access databases and Excel spreadsheets to manage OIT's $44 million budget and expenditures, and
- Manual procedures to collect and analyze project cost, schedule, and performance data from separate stand-alone databases and spreadsheets maintained by project managers, acquisition and contract administration personnel, budget and finance personnel, and other supporting organizational elements within OIT.
We concluded that these control mechanisms provide OIT a "high-level" capability to manage the cost, schedule, and performance of IT projects. However, OIT needs to do more in this aspect of its PMM to implement OMB's instructions for complying with legislative mandates.
We discuss areas that require more emphasis by management below.
SUPPORT AND ENABLING PROCESSES
Our audit showed that project managers were generally adhering to the prescribed requirements of OIT's PMM. However, an overall theme brought to our attention by OIT office heads, project managers, and program area personnel performing project management evolved around the difficulty they encountered in obtaining and generating the information needed to implement and comply with the operational and procedural requirements of OIT's project management methodology. As a result, project managers either inconsistently implemented OIT's standardized and repeatable PMM procedures, or they established inconsistent work arounds and alternative methods to perform project management responsibilities.
OIT's capability to achieve cost efficiencies afforded by establishing repeatable project management processes is diminished by the absence of, and/or the incompatibility of OIT's PMM support and enabling processes. These operational inconsistencies also introduce unmitigated risks, which compromise the effectiveness of OIT's project management internal controls.
Recommendation D
OIT should pilot and test project management policies, practices, and procedures before mandating that project managers adhere to them to make sure that support and enabling processes are in place to implement OIT's PMM.
OIT concurred with Recommendation D and stated that it will establish formal test and evaluation procedures that will be incorporated into its project management methodology development and review process.
TRACKING AND OVERSIGHT CONTROLS
Project management controls over program area managed IT projects needed strengthening. In addition, OIT's automated and manual control procedures did not provide a standardized and integrated control system for managing project costs (contractor and government) by their work breakdown structures. And, OIT did not have a project management information system to capture the requisite cost, schedule, and performance-based data to enable effective performance-based acquisition analyses.
Program Area Managed Projects
Program office personnel performed project management for three of the eight projects included in the scope of our audit having an estimated cost of $5.9 million. However, OIT and Commission policy does not include guidance and instructions that outline the project management processes, controls, and procedures applicable to Commission program offices when they manage IT initiatives.
Program office personnel managing IT projects stated that they were not familiar with OIT's project management methodology, nor were they familiar with their responsibilities for complying with legislative mandates governing project management. In addition, program office personnel that we interviewed stated that they performed Contracting Officers' Technical Representative (COTR) responsibilities before receiving formal COTR training. For example, in August 2000 a program office awarded an IT contract valued at $4.9 million. However, the individual designated as the COTR for the IT project did not receive formal COTR training until July 2001.
In August 2001, the Commission adopted an IT Governance process to strengthen its controls over how the Commission selects, manages, and evaluates the performance goals for its $44 million IT capital investment portfolio (IT Decision Making Process (OIG Report No. 334), dated August 28, 2001). We believe the risks associated with program area managed projects further justify increased management attention on how program offices manage and account for resources programmed for IT projects.
OIT and the Commission will increasingly rely upon Information Officers (IO's) to provide sound justification for a project's strategic alignment to Commission goals. IO's will also serve as the primary control for making sure that project management and IT capital investment recommendations provide the Commission's executives a sound basis to approve the use of IT resources to achieve efficient and effective organizational outcomes.
Recommendation E
OIT, in coordination with OED, heads of program offices, and the IO Council, should establish, implement, and enforce a project management SECR that specifies the project management and contracting procedures that program offices are to follow and implement when they perform project management for information technology projects.
OIT concurred with Recommendation E and stated that it is already working with sponsoring organization project personnel to ensure that they are aware of existing guidance.
Monitoring Contractor Performance
OIT's automated and manual control procedures - Financial Systems Application (FSA), procurement database, project status reports, statements of work, contractor billings, use of Microsoft Project, and year-end budget/execution analyses - do not provide a standardized and integrated control system for managing project costs (contractor and government) by their work breakdown structures. Inconsistencies in project naming conventions, data descriptions, data structures, and data collection methods and practices diminish OIT's, and the Commission's, capability to effectively track and control project budgeting and execution, and the contractor billing activities of an IT project. According to OIT management, the Commission's financial management system does not provide OIT the capabilities to track and manage costs and contract invoicing, which are necessary to effectively support project management controls.
In addition, OIT has not established guidelines that standardize the PMM content project managers are to incorporate into statements of work, to include the requirement for contractors to link their "gross" hourly billings to specific contract line items and deliverables. As a result, project managers have developed inconsistent manual methods and procedures to establish contractor performance thresholds and to monitor, control, and verify the performance of contractors when approving contractor-billings for payment.
The Federal Acquisition Streamlining Act (FASA) of 1994 requires the heads of Federal agencies to establish IT financial management and control systems that accumulate actual costs of projects by their work breakdown structures. In addition, project management and control systems should provide management the capability to track costs by the contract's major elements, and to integrate those costs with performance indicators to give project managers, and IT governance officials, a clear understanding of how resources connect to results.
Recommendation F
OIT should standardize project naming conventions, data descriptions, data structures, and data collection methods and practices for internal budgeting, contracting, and project management functions.
Recommendation G
OIT should establish guidelines to standardize the PMM content that project managers are to incorporate into statements of work (including the requirement for contractors to link their "gross" hourly billings to specific contract line items and deliverables) and OIT should also assure that a contract's major cost elements map to the SDLC PMM.
Recommendation H
OIT should establish an integrated project management tracking and control process (capitalizing on the capabilities and efficiencies that the deployment of Momentum4 affords the Commission in integrating project management into its financial management and cost reporting system) to track, monitor, and report the status of an IT contract's major cost elements.
OIT concurred with Recommendations F, G, and H and stated that along with interim changes that it is making to its internal financial systems and data, it will work with Procurement and Contracting and the Comptroller to design and implement recommended changes.
Acquisition Analysis and Performance-based Management
OMB recommends that Federal agencies utilize performance-based management to effectively manage the cost, schedule, and performance goals of IT projects to comply with FASA. Performance-based management systems should provide useful information for all levels of the project management team. OMB recommends using the following eight metric categories to provide useful project management information for analysis.
Category | Category |
1. Change control | 4. Performance variance |
2. Understanding whether technical objectives are being achieved | 5. Variance analysis |
3. Cost variance | 7. Identification of problem areas at both the organization and work breakdown structure levels |
4. Schedule variance | 8. Variance at completion analysis |
During our audit, we could not effectively evaluate the Commission's compliance with the cost, schedule, and performance variance thresholds mandated by FASA. We could not reasonably evaluate the Commission's compliance with FASA because OIT did not have a project management information system to capture the requisite cost, schedule, and performance-based data to enable effective acquisition analyses.
In addition, OIT found it difficult to adequately estimate project costs, develop accurate project schedules, and establish realistic project work packages and work breakdown structures because program offices did not:
- Address their intended performance goals to be gained from IT investments,
- Perform adequate requirement analyses for requested projects, or
- Prepare well-defined IT business cases for proposed IT investments.
OIT needs to establish a project management information system that effectively collects operational information, which identifies unproductive project management activities and provides a sound basis to implement cost-effective and value-based project management practices.
Recommendation I
OIT, in coordination with the OED, program office heads, and IO's, should implement a cost-effective project management performance-based acquisition analysis process that builds upon recommendations E through H of this audit report to comply with OMB's guidance for implementing the Federal Acquisition Streamlining Act.
OIT concurred with Recommendation I without comment.
APPENDIX A
PROJECTS SELECTED FOR REVIEW
Name of Project | Program Area 2 | Project Source 3 | Project Management Methodology Phase | FY 01 Budgeted Amount as of 6/30/01 |
NSAR Short Term | IM | CPC | Initiation | 315,000 |
Electronic Filing Study | MR/OFIS | CPC | Initiation | 300,000 |
Bluesheet | ENF | CPC | Analysis/ Requirements | 527,000 |
Momentum | OC | OIT | Analysis/ Requirements | 928,000 |
FOIA Tracking System | OFIS | CPC | Design | 572,486 |
IARD | IM | CPC | Implementation/ Deployment | 3,660,000 |
Internet Search Engine | ENF | CPC | Implementation/ Deployment | 1,400,000 |
EDGAR 7.5 VV&T | OIT | Testing | 405,107 | |
Total | 8 | $8,107,593 |
APPENDIX B
LEGISLATIVE MANDATES FOR MANAGING IT PROJECTS
Investment Control
Section 5122 of the Clinger-Cohen Act of 1996 (Public Law 104-106) requires the head of each executive agency to establish project management methods and practices that provide management and stakeholders the means to obtain timely and useful project management information regarding the:
- Progress of an investment in an information system;
- Achievement of cost and schedule goals established for the investment; and,
- Attainment of the operational capability requirements expected from the investment.
The methods and practices should provide, on an independently verifiable basis, the capability to timely measure progress in meeting established project milestones in terms of cost, schedule, and operational performance expected from the investment.
Earned Value Concept
OMB Memorandum M-97-18, Capital Programming Guide, Supplement to A-11, Part 3, dated July 22, 1997 mandates the use of an earned value or similar project management system to provide management adequate visibility on the achievement of, or deviation from, a projects goals until the project is accepted and operational.
Earned value is a project management technique that relates resources planning to schedules and to technical, cost, and schedule requirements. Under this technique, management plans, budgets, and schedules al work in time-phased "planned value" increments, which constitute a cost and schedule measurement baseline. There are two major objectives of an earned value system:
- Contractors are encouraged to use effective internal cost and schedule management control systems; and,
- Federal agencies can rely on timely data produced by the cost and schedule control systems for determining product-oriented contract status.
Implementing an earned value project management system versus the typical spend comparison approach, whereby contractors report actual expenditures against planned expenditures, provides management a much more effective tool to measure the validity of a projects "true" status in terms of established cost, schedule, and performance goals.
Acquisition Analysis
Title V, Section 5051of the Federal Acquisition Streamlining Act (FASA) of 1994 (Public Law 103-355) mandates how executive agencies are to manage and control the acquisition of an information technology investment (as defined by the organization, or as defined by the minimum thresholds established by OMB). Once an information technology investment contract i.e., task order is issued/awarded, it is to be managed to achieve, on average, at least 90 percent of the cost, schedule, and performance goals established for the investment throughout its life-cycle. The contractor should use a performance-based management system, as specified in the contract, to provide management information on the actual accomplishment of the work completed as compared to the baseline goals established for the project.
Agency information technology investment financial management and control systems should accumulate actual costs of the project by its work breakdown structure, including both contract costs and government program/project management costs. In addition, the management and control system should provide management the capability to track costs by major element of the contract, and to integrate those costs with performance indicators to give project managers a clear understanding of how resources are connected to results. If the acquisition is not achieving at least 90 percent of its cost, schedule or performance goals, management should determine the reasons for the deviations, the corrective actions planned by the contractor/developer, and whether the corrective actions are likely to achieve baseline goals within established completion dates. If not, management should terminate the project, or return the project to the selection committee to determine a new approach to achieving mission objectives.
APPENDIX C
SEC PROJECT THRESHOLD CRITERIA
OIT internal policy document 22-5-001-001.1 titled "What is a Project", dated July 18, 2000, establishes OIT policy and Commission guidance for information technology project thresholds requiring approval by the Information Technology Capital Planning Committee (ITCPC). An information technology initiative is considered requiring special management attention if it:
1. Has a minimum cost of $25,000;
2. Has a minimum life cycle of two months or more;
3. Will involve more than one SEC division or office; or,
4. Will affect a significant number of SEC users.
An information technology initiative meeting any one of the four criteria is managed as a project, and is assigned a project manager who is responsible for managing the project's cost, schedule, and performance goals in accordance with OIT's project management methodology.
APPENDIX D
PROJECT MANAGEMENT PROCESSES VERSUS SDLC PROCESSES
Project management is comprised of a series of activities designed to accommodate an organization's System Development Life Cycle (SDLC) approach for identifying, developing, and delivering a fully functional IT initiative to the organization's users within cost and schedule. Although project management methodologies vary among organizations, the methodology adopted by an organization should establish the enabling policies, practices, procedures, and framework to compliment the organization's SDLC environment. The methodology should also define and establish repeatable processes that enable the attainment of efficient and effective project management activities. The relationship of project management activities to the development life cycle phases of a project is depicted in the diagram below.
Under OIT's current Project Management Methodology, in-house project managers perform project management processes, while contractors perform most system development life cycle activities under service contracts.
APPENDIX E
WORK BREAKDOWN STRUCTURE OF A PROJECT
A work breakdown structure (WBS) allows a project manager to decompose a project's tasks and activities into manageable work packages to facilitate project planning and control. This is illustrated in the chart below.
The work packages serve as the foundation for resource planning, resource allocation, time schedules, and budget plans.
APPENDIX F
SOFTWARE ENGINEERING INSTITUTE'S (SEI) SOFTWARE CAPABILITY MATURITY MODEL (CMM)
Organizations that have a repeatable software development process-one that can be counted on to render the same results if the same processes are followed-have been able to significantly improve their productivity and return on investment. According to the SEI, processes for a repeatable capability (CMM level 2) are considered the most basic in establishing discipline and control in software development and are crucial steps for any project to mitigate risks associated with cost, schedule, and quality. As shown in the table below, these procedures include (1) requirements management, (2) software project planning, (3) software project tracking and oversight, (4) software subcontract management, (5) software quality assurance, and (6) software configuration management.
CMM Level 2 "Repeatable" Key Process Area (KPA) Descriptions
CMM Level 2 KPAs | Description |
Requirements Management | Defining, validating, and prioritizing requirements, such as functions, performance, and delivery dates. |
Software project planning | Developing estimates for the work to be performed, establishing the necessary commitments, and defining the plan to perform the work. |
Software project tracking and oversight | Tracking and reviewing software accomplishments and results against documented estimates, commitments, and plans and adjusting these based on the actual accomplishments and results. |
Software subcontract management | Selecting qualified contractors and managing them effectively. |
Software quality assurance | Reviewing and auditing the software products and activities to ensure that they comply with the applicable processes, standards, and procedures and providing the staff and managers with the results of their reviews and audits. |
Software configuration management | Selecting project baseline items, such as specifications; systematically controlling these items and changes to them; and recording and reporting status and change activity for these items. |
APPENDIX G
PROJECT MANAGEMENT POLICIES AND PROCEDURES
AS OF MAY 16, 2001
OIT Policies & Procedures: Project Management
Approved Documents
Index # | Title | Date Approved | Comment |
Project Management Overview | |||
22-25-001-001.1 | What is a Project? | 07/18/2000 | |
22-25-007-001.0 | Project Management Methodology Policy | 01/23/2001 | |
22-25-018-001.0 | Project Management Plan (PMP) Procedures Project Management Plan (PMP) Template | 07/17/2001 | |
22-25-003-001.0 | Project Team Roles & Responsibilities Cover Sheet Project Team Roles & Responsibilities Slides | 09/06/2000 | |
Initiation Click for flowchart | |||
80-35-005-001.2 | Configuration Control Request (CCR) Procedures Configuration Control Request (CCR) Template | 09/25/2001 | |
22-25-013-001.0 | Initiation Phase Procedures Initiation Phase Process Flow | 06/12/2001 | |
22-25-009-001.0 | Lessons Learned Procedures Lessons Learned Template | 03/20/2001 | |
22-25-004-001.0 | Project Kickoff Meeting Guideline | 09/06/2000 | |
22-25-006-003.0 | Project Packet Procedures Project Packet Template Project Packet Section A Review/Approval Template | 05/03/2001 | |
22-25-005-003.0 | Project Schedule Procedures COTS Project Schedule Boilerplate Generic Project Schedule Boilerplate Infrastructure Project Schedule Boilerplate | 09/25/2001 | |
QA Checklist: Project Initiation Phase | TBD | ||
22-25-016.001.0 | Risk Identification Table | ||
22-25-015.001.0 | Risk Management Plan Risk Management Template | 07/10/2001 | |
Statement of Work (SOW) Template & Instructions | TBD | ||
Analysis & Requirements Click for flowchart | |||
22-25-010-001.0 | Design Assistance Request Signoff Procedures Design Assistance Request Template | 03/27/2001 | |
Project CM Plan/Template | TBD | ||
Project Security Plan/Template | TBD | ||
Project QA Plan/Template | TBD | ||
QA Checklist: Project Analysis Phase | TBD | ||
22-25-008-001.0 | Requirements Gathering Guideline Attachment A: Requirements Questionnaire | 01/23/2001 | |
Requirements Traceability Matrix (RTM) | TBD | ||
22-25-012-001.0 | Technical Requirements Review Procedures Technical Requirements Review Signoff Template | 06/12/2001 | |
Test & Evaluation Master Plan (TEMP) | TBD | ||
Design | |||
Deployment & Implementation Plan | TBD | ||
Design Specifications Procedures | TBD | ||
Design Specifications Signoff & Instructions | TBD | ||
Maintenance Plan | TBD | ||
QA Checklist: Design Phase | TBD | ||
22-25-011-001.0 | Standard Operational Procedures (SOP) Standard Operational Procedures (SOP) Template | 04/17/2001 | |
Test Readiness Review (TRR) Checklist | TBD | ||
Training Plan | TBD | ||
Development | |||
CM Application Changes during Development | TBD | ||
80-35-001-002.0 | Data Services Request (DSR) Procedures Data Services Request (DSR) Template | 03/27/2001 | |
Integration Testing Procedures | TBD | ||
QA Checklist: Project Development Phase | TBD | ||
Ready to Test Packet Documentation | TBD | ||
Test Readiness Review (TRR) Procedures | TBD | ||
TRR Signoff & Instructions | TBD | ||
User Manual | TBD | ||
Testing | |||
Broadcast Message Procedures | TBD | ||
CM Test Build Procedures | TBD | ||
80-27-004.001.0 | Infrastructure Testing Signoff Procedures Infrastructure Testing Signoff Template | 07/17/2001 | |
Production Readiness Review (PRR) Procedures | TBD | ||
Production Readiness Review (PRR) Signoff & Instructions | TBD | ||
QA Checklist: Testing Phase | TBD | ||
QA Testing Procedures | TBD | ||
80-27-005.001.0 | Quality Assurance Testing and Review Signoff Procedures Quality Assurance Testing and Review Signoff Template | 07/17/2001 | |
User Acceptance Testing Signoff & Instructions | TBD | ||
VV&T Signoff & Instructions | TBD | ||
Training | |||
21-08-001-001.0 | Project Training Checklists Attachment A: Checklist for Training Review Attachment B: Detailed Training Checklist | 03/28/2000 | |
QA Checklist: Training Phase | TBD | ||
Training Checklists | TBD | ||
Training Tools | TBD | ||
Deployment and Implementation | |||
CM Production Build | TBD | ||
Production Checklist | TBD | ||
Production Readiness Review Procedures | TBD | ||
QA Checklist: Deployment & Implementation Phase | TBD | ||
Acceptance and Closeout | |||
Acceptance & Closeout Letter (Signoff) | TBD | ||
CM & QA Closeout | TBD | ||
QA Checklist: Acceptance & Closeout Phase | TBD | ||
Project Tracking & Oversight | |||
OCCB Presentations | TBD | ||
21-25-001-001.0 | Status Report Instructions Status Report Template Status Report Spreadsheet | 11/21/2000 | |
TRB Presentations | TBD | ||
Standards | |||
Coding Standards | TBD | ||
Infrastructure Standards | TBD | ||
Naming & Numbering Conventions Standards | TBD | ||
21-25-002-001.0 | OIT Glossary | 04/17/2001 | |
Standard Data Dictionary | TBD | ||
30-03-002-001.0 | Standard Web-based Applications Architecture | 02/14/2001 | |
Testing Standards | TBD | ||
General Guidelines | |||
Application Requirements Generation | TBD | ||
Configuration Management Plan | TBD | ||
22-02-001-001.0 | Meeting Protocol | 09/12/2000 | |
22-25-019.001.0 | Procedures for Posting OIT Project Files | 07/10/2001 | |
22-25-017-001.0 | Project Checklist | 07/17/2001 | |
Quality Assurance Plan | TBD | ||
22-25-002-001.1 | Routine Tasks | 07/18/2000 | |
30-03-001-001.0 | Software Product Migration Procedures | 10/10/2000 | |
System Change Requests (SCR) | TBD | ||
Test Problem Reports (TPR) | TBD |
OIT Home | OIT Policies & Procedures Home |
/cmqa/pm.htm
Last Update: 05/16/2001
APPENDIX H
PROJECT MANAGEMENT BOARD STRUCTURE
APPROVAL TABLE BY SDLC PHASE
Review/Approval Board | Responsibilities |
Project Review Board (PRB) |
|
Organization Configuration Control Board (OCCB) |
|
Technical Review Board (TRB) |
|
Board Approvals Required | ||||
Project Phases | PRB | OCCB | TRB | USER |
Initiation | A | N | N | NAR |
Requirements Definition | N | N | N | A |
Analysis/Technical Requirements | N | N | A | NAR |
Design | N | N | A | NAR |
Development | N | N | A | NAR |
Testing | N | N | A | A |
Training | N | N | N | A |
Implementation/Deployment | N | N | A | NAR |
Acceptance/Closeout | N | A | N | NAR |
LEGEND
A = Approval
N = Notification
NAR = No Action Required
1 During the audit, OIT adapted its CMM-SW methodology to comply with the SEI's Capability Maturity Model Integrated (CMMI). CMMI is a more comprehensive methodology than CMM-SW in that it addresses operational processes in addition to software development processes.
4 Momentum is the accounting system that will replace the Federal Financial System (FFS), which is the Commission's current accounting system.
2 Division of Investment Management (IM); Division of Market Regulation (MR); Office of Filings and Information Services (OFIS); Office of the Comptroller (OC)
3 Capital Planning Committee Approved Project (CPC); Office of Information Technology Sponsored Project (OIT)
Last Reviewed or Updated: June 10, 2004