DOD has not effectively managed important aspects of the requirements for DIMHRS (Personnel/Pay) to ensure that they are complete, correct, and unambiguous. Requirements are the foundation for designing, developing, and testing a system. Incorrect or incomplete requirements have been commonly identified as a cause of systems that do not meet their cost, schedule, or performance goals. Disciplined processes and controls for the definition and management of requirements are defined in published models and guides, such as the Capability Maturity Models developed by Carnegie Mellon University’s Software Engineering Institute and standards developed by the Institute of Electrical and Electronics Engineers. DOD’s management of DIMHRS (Personnel/Pay) requirements had several shortcomings: First, DOD did not initially ensure that the system requirements and system design were aligned. DOD required the contractor to base the system design only on high-level (more general) requirements, providing detailed requirements to the contractor for information only. However, according to the program office, the system design should be based on the detailed requirements, and following our inquiries, the program office began tracing backward and forward between the detailed requirements and the system design to ensure consistency. Among other things, DOD is analyzing financial system standards to ensure that all applicable standards are included in the requirements and design for DIMHRS (Personnel/Pay). Without consistency between requirements and design, the risk is increased that the developed and deployed system will not fully satisfy financial system standards and users’ needs. Second, DOD did not ensure that the detailed requirements include important content and that they are clear and unambiguous. The requirements for the interfaces between DIMHRS (Personnel/Pay) and existing systems are not yet complete because DOD has not yet determined the extent to which legacy systems will be replaced and thus require modification in order to interact with the new system. Furthermore, DOD is still determining whether the data requirements provided to the contractor for system design are complete. Finally, about 77 percent of the detailed requirements are difficult to understand, based on our review of a random sample of the requirements documentation. Our review showed that this documentation did not consistently provide a clear explanation of the relationships among the parts of each requirement (business rules; information requirements; and references to regulations, laws, standards, and so on) or adequately identify the sources of data required for computations. If requirements are not complete and clear, their implementation in the system is not likely to meet users’ needs. Third, DOD has not obtained user acceptance of the detailed requirements. As we have pointed out, when business process changes are planned, users’ needs and expectations must be addressed, or users may not accept change, which can jeopardize the effort. One way to ensure and demonstrate user acceptance of requirements is to obtain sign-off on the requirements by end-user representatives. However, although the DIMHRS (Personnel/Pay) program obtained the user organizations’ formal acceptance of the high-level requirements, the process used to define the detailed requirements has not resulted in such acknowledgment of agreement on the requirements. Program officials stated that gaining formal agreement from some of the user organizations would delay the program and be impractical because of end users’ reluctance to accept a set of joint requirements that requires end users to make major changes in their current ways of processing military personnel and pay actions. We have previously observed this challenge and have stated that DOD’s organizational structure and embedded culture work against efforts to modernize business processes and implement corporate information systems such as DIMHRS (Personnel/Pay) across component lines. Nevertheless, not attempting to obtain agreement on DIMHRS (Personnel/Pay) requirements increases the risk that users will not accept and use the developed and deployed system, and that later system rework will be required to make it function as intended DOD-wide and achieve stated military human capital management outcomes. According to DIMHRS (Personnel/Pay) officials, a number of actions have been taken to reduce the risk that users will not accept the system, including conducting numerous focus groups, workshops, demonstrations, and presentations explaining how the DIMHRS (Personnel/Pay) software product could address DOD’s existing personnel/pay problems. However, DIMHRS (Personnel/Pay) officials stated that support for the system by the services’ executives is mixed. For example, the officials said that (1) Army executives are committed to implementing and using the DIMHRS (Personnel/Pay) system because they believe it will address many problems that the Army currently faces; (2) Air Force officials generally support the system but say they do not yet know whether the system will meet all their needs; and (3) Navy and Marine Corps executives are not as supportive because they are not fully convinced that DIMHRS (Personnel/Pay) will be an improvement over their existing systems. The shortcomings in DOD’s efforts to effectively manage DIMHRS (Personnel/Pay) requirements are attributable to a number of causes, including the program’s overly schedule-driven approach and the difficulty of overcoming DOD’s long-standing cultural resistance to departmentwide solutions. These shortcomings leave DOD without adequate assurance that the requirements will accurately reflect the end users’ needs and that the resulting system design is reflective of validated requirements that will fully meet DOD’s needs. DOD does not have a well-integrated structure for managing DIMHRS (Personnel/Pay), which DOD has described as an integrated program, and it is not following some key supporting processes for acquiring COTS-based business systems. Program responsibility, accountability, and authority are diffused. Leading organizations ensure that programs are structured to ensure that a single entity has clear authority, responsibility, and accountability for the program. For DIMHRS (Personnel/Pay), these are spread among three key stakeholder groups whose respective chains of command do not meet at any point below the Secretary and Deputy Secretary of Defense levels. Responsibility for requirements definition rests with a joint requirements development office, which is accountable through one chain of command. Responsibility for system acquisition rests with the program office, which is accountable through another chain of command. Responsibility for preparing for transition to the new system rests with the end-user organizations—11 major DOD components reporting through five different chains of command. This is consistent with our earlier observation that DOD’s organizational structure and embedded culture have not adequately accommodated an integrated, departmentwide approach to joint systems. Without a DOD-wide integrated governance structure for a joint, integrated program like DIMHRS (Personnel/Pay), the risk is increased that the program will not produce an integrated set of outcomes. The system has not been defined and designed according to a DOD-wide integrated enterprise architecture. In accordance with the National Defense Authorization Act for Fiscal Year 2003, DOD has been developing a departmentwide Business Enterprise Architecture (BEA), and it has been reviewing some programs, such as DIMHRS (Personnel/Pay) with proposed obligations of funds greater than $1 million, for consistency with the BEA. In April 2003, the DOD Comptroller certified DIMHRS (Personnel/Pay) to be consistent with the BEA on the basis of the program manager’s commitment that the yet-to-be-developed system would be designed to be consistent with the yet-to-be-developed architecture. To follow through on this commitment, DOD included a requirement in the DIMHRS (Personnel/Pay) contract that the systems specification be compatible with the emerging BEA. DIMHRS (Personnel/Pay) officials recognize that the April 2003 architectural certification is preliminary and stated that DIMHRS (Personnel/Pay) will undergo another certification before the system deployment decision. By that time, however, lengthy and costly design and development work will have been completed. The real value in having and using an architecture is knowing during system definition, design, and development what the larger blueprint for the enterprise is, so that these can be guided and constrained by this frame of reference. Aligning to the architecture after the system is designed would require expensive system rework to address any inconsistencies with the architecture. Program stakeholders’ activities have not been managed according to a DIMHRS (Personnel/Pay)-integrated master plan/schedule. An effective master plan/schedule should allow for the proper scheduling and sequencing of activities and tasks, allocation of resources, preparation of budgets, assignment of personnel, and criteria for measuring progress. However, the DIMHRS (Personnel/Pay) program plan/schedule is based on the contractor’s and program office’s activities and does not include all the activities that end-user organizations must perform to prepare for DIMHRS (Personnel/Pay), such as the redesign of legacy systems and interfaces, business process reengineering, and workforce change management. Without a true master plan/schedule of activities that includes all DOD program stakeholders, the risk increases that key and dependent events, activities, and tasks will not be performed as needed, which in turn increases the risk of schedule slippage and program goal shortfalls. Some, but not all, best practices associated with acquiring COTS-based business systems are being followed. An example of a best practice that DOD is following is to discourage the modification of commercial software components without thorough justification; DOD’s contract includes award fees that give the contractor incentives to, among other things, minimize the customization of the COTS software. An example of a best practice that DOD is not following is to ensure that plans and schedules explicitly provide for preparing users for the new business processes associated with the commercial components. DOD does not have an integrated program plan/schedule that provides for end-user organization activities that are associated with preparing users for the changes that the system will introduce.