SPAWAR Systems Center - San Diego Enterprise Resource Planning Project Charter

1. SPAWAR Systems Center - San Diego Enterprise Resource Planning Project Charter EI Toolkit 1 Document version 1.0, December 2000 EITK0604 Last validated: December 2003

2. INTRODUCTION This Charter provides an overall view of the Enterprise Resource Planning (ERP) effort at SPAWAR Systems Center - San Diego (SSC-SD). Project Cabrillo, which is the name for this ERP effort, will provide improved end-to-end business processes with reduced cost of business operations. The information in this Charter reflects the current state of the project as of the publication date. Its content will be updated throughout the various project phases to reflect the current state of Project Cabrillo.

3. Project Overview…………………………………...5 Executive Summary……………………………….6 Project Objectives……………………………...….7 Project Mission Statement……….…..……………8 Critical Success Factors……………………..…….9 Concept of Operations Overview……………..…14 Project Scope……………………………………...15 Process Scope…………………………………….17 XYZ Functional Scope………….……………...…20 Organizational Scope…………………………….22 Technical Infrastructure Scope…………………..23 Interface Scope……………...……………………24 Data Conversion Scope…………….……….……26 Reports, Data Retention and Forms Scope ...……27 Change Management Scope…………………..….28 Training Scope…………………………………...29 Controls and Security Scope……………………..30 Project Strategy………………………………...…31 Technical Architecture Strategy………………....32 Change Management Strategy………………...…34 Training Strategy……………………………...…35 Test and Evaluation Strategy…………………….36 Implementation and Roll-out Strategy…..………38 Development Strategy…………………………...39 Project Charter Table of Contents

4. Project Management………….………………….40 Plan of Action and Milestones………………..….41 Work Plan………………………………….……..42 Ascendant XYZ Project Methodology ………...…45 Risk Management………………………………..46 Issue Management ………………………….……47 Scope Management……………………………....48 Project Planning and Monitoring…………...……49 Project Organization………………………..……51 Navy ERP Pilots………………………………....52 SSC San Diego………..…………………………53 Team Roles and Responsibilities……………..…58 Assumptions…………………………………...…..59 Appendices…………………………………...……60 A. Team Roles and Responsibilities….………...…61 B. Concept of Operations………….………...…….72 C. Project Work Plan…....……....…….…………..99 Project Charter Table of Contents(continued)

5. Executive Summary Project Objectives Project Mission Statement Critical Success Factors Concept of Operations Project Overview

6. Executive Summary The SPAWAR Systems Center-San Diego has embarked on a journey of change. By volunteering to participate in a Navy Enterprise Resource Planning (ERP) Pilot Program as the Navy Working Capitol Fund (NWCF) Activity, the SPAWAR Systems Center San Diego began planning for that journey. The Navy Executive Committee for Revolution in Business Affairs and the Commercial Best Practices Executive Steering Group have asked the Center to perform a Pilot Program for Warfare Center Financial Management-Enterprise Resource Planning. This Pilot Program will determine the feasibility of implementing similar systems at other NWCF activities. The Pilot Program will complete in two years, and capability rollouts at SPAWAR Headquarters and other activities are expected. SPAWAR Systems Center-San Diego is seeking to modernize its many applications and information systems and will implement select modules from XYZ’s software package. This technology will enable NWCF management to have the capability and flexibility to redesign existing business practices to better align with best commercial practices. The ERP will make the SPAWAR Systems Center-San Diego able to avoid the reduced competitiveness brought about by aging stovepipe systems that cannot provide up-to-date, certified, financial information.

7. Project Cabrillo is to incorporate best commercial business practices utilizing Commercial Off-The-Shelf software, providing integrated data, and workflow processes. ERP technology will enable SSC-SD to have the ability and flexibility to redesign existing business processes to be more in line with best commercial practices. To this end, Project Cabrillo will integrate and implement an SSC-SD Enterprise-wide functional business area, primarily focusing on Financial Management for Working Capital Fund Activities with total integration of other RDT&E business functional capability. The functional capability includes, in addition to the Financial Management, Procurement/Supply Management, Project Management, Asset Management (e.g. property management), and Business Strategic Planning. Project Objectives

8. To provide integration of business processes that optimizes functions across the Warfare Center Management Enterprise. To provide consistent and reliable information for timely decision making and performance measurement. Fully Integrate data across functional lines Enter data only once, into a single database, with common user interface and common tools. Bottom line: Eliminate stovepipes/duplication Improve productivity/efficiency Reduce cost of doing business Ultimate objective is initiating and sustaining business change, not just implementing a software package. Project Mission Statement

9. Decision Making Project Management People/Teams Process Organization Training Systems Sustaining Support Critical Success Factors The Critical Success Factors (CSF) identified under the following categories are applicable specifically to Project Cabrillo. By adhering to these CSFs throughout the project, the management team will create an environment where an essential project requirement can be addressed in a reasonable and timely fashion.

10. Timely Decision-Making Rapid decision making at every level - resolve issues at the right level Issues are documented, described, ownership assigned, closure date determined, alternatives presented and a recommendation made Issues are monitored by team leaders and project management and an issue escalation procedure is followed for unresolved issues Executives must respond rapidly when needed, monitor the level at which issues are getting resolved and ensure decisions are not re-visited. Project Management The work plan for the multiple teams will be in sync, from a critical path point of view, and will be monitored as a single, integrated work plan Keen focus on critical path activities with appreciation for the integration and interdependence of all activities Scope management Executives must help navigate and prioritize, particularly unforeseen events. Critical Success Factors

11. People/Teams Core-team members must be our best, 100% committed to the project and co-located Teams empowered at the right level Executive Commitment - must be actively involved in the project through a Steering Committee comprised of business unit executives Executives demonstrate support via resource allocation and empowerment of decision-making Process Old, inefficient, ineffective practices must be eliminated By the end of the Blueprint stage, organizational structure and master data for the project must be frozen Appropriate integration with Echelon 2 (HIT/HAT) Subject matter experts must make themselves available to the project as required Key business executives must “own” the business processes and policy decisions User Community “buy-in” Executives must ensure that the business owners really own the process and policies… part of their performance metrics Critical Success Factors

12. Organization The organization must be willing to change. Establish a formal organization “readiness” program that is integrated into the implementation strategy. Executives must be the champions of change Executives “walk the talk”… in your business plans, part of your conversations, obvious enthusiasm, long-term support. End User Training Organizational ownership of the training program Select a set of End Users as Champions to offer training input, deliver training and serve as local XYZ functional experts Ensure business processes, job roles and organization changes, if any, are incorporated into the training Executives support the “holistic” training approach, time away from the business. Critical Success Factors

13. Systems Business process will utilize XYZ’s capabilities and avoid need for software modification - “NO MODS” Design the system to be scaleable to support growth Freeze legacy systems in advance of integration testing Executives ensure commitment to these principles. Sustaining Support The system must be in place for sustaining operations. A help desk must be up, operational and tested well before the departure of the systems integrator Executives ensure a strong, trained IT organization is in place to support the business. Critical Success Factors

14. XYZ has been selected by SPAWAR Systems Center - San Diego (SSC-SD) as the software for implementation of the Echelon III Navy Working Capital Fund (NWCF) Enterprise Resource Planning (ERP) pilot site for financial management. XYZ consists of a number of integrated financial, material management, project management, and other modules that support the spectrum of business processes. The purpose of the Concept of Operations is to provide a high level view of key business elements and includes description, interfaces, XYZ module, scope, and issues or implementation considerations. Sections are grouped by enterprise area, summarizing major processes or business functions and noting overlaps/integration points. The Concept of Operations document describes (Appendix B) top-level business functions that have been defined during the detailed blueprinting phase. Some processes/transactions may be adjusted during configuration. Concept of Operations Overview

15. Process Scope identifies processes, process chains, and activities within the scope of the Wave 1 project as well as the processes and activities deferred to Wave 2. XYZ Functional Scope defines the scope of the XYZ functionality, including enhancements (bolt-ons), to support the process scope. Organizational Scope defines the business unit components of the Wave 1 implementation, who will be primary owners and users of the new functionality. Technical Infrastructure Scope defines the hardware, systems software, and communications scope for the development, testing, training and production environments. Interface Scope outlines the planned data flows between XYZ and external systems. Data Conversion Scope defines the magnitude of the data conversion efforts to create opening data in the XYZ production system. Reports, Data Retention, and Forms Scope defines any exceptional reporting and form generation requirements that may have an impact on scope. Change Management Scope identifies the scope of change activities to assure that the SSC-SD community understands and is ready for the impact and timing of the implementation. Training Scope defines the target audience and timing for end user training. Controls and Security Scope identifies business process controls, security structure scope and controls for the system development/production environments. Project Scope The purpose of this section is to establish the framework for the project scope. The scope of Project Cabrillo was defined considering the five major business areas identified at the start of the project, and the primary emphasis or foundation of the project is on financial management and other processes having financial implications. Unless otherwise noted, the scope definition refers to Wave 1 only. Scope definition includes scope content and boundary or approach definitions for the following levers of scope:

16. Business Process Scope - Business Areas • Financial Management • All financial activities including budgets, funds management, billings, payables, reporting and employee data • Materials Management • All buying activities for MRO items, from issuing PO, receipt of goods and processing vendor invoices • Complex contracting deferred to Wave 2 • Asset Management • Includes both real property and improvements. Tracks all assets from acquisition to disposal • Project/Program Management • Fully integrated project management system that ties together project management tools with finance, budgeting, procurement and asset management data • Strategic Management • Planning and budgeting tool for both annual and long range planning • Business Information Warehouse deferred to Wave 2

17. Funds Management Reimbursable Orders Direct Cite Funds Control Reimbursable Billing Mechanical Bills Advance Liquidation Billing Reject Correction Encumbrance Posting Commitments Obligations Accruals Cost Liabilities Vendor Pay Vendor Master Vendor Invoice Processing and Certification Accounts Payable Accounts Receivable Treasury Daily Cash/Interfund Bills Activity Cash Reconciliation Cash Correction/ Cash Transfers Misc. Cash Adjustments (SF 1081) General Ledger/Financial Statements Financial Management Month-End DONIBIS/CDB Year-end Closing/Adjustments Asset Management Capital Purchases Contributed Assets Sponsor-Owned Equipment Depreciation Physical Inventory/Custody Maintenance Process Scope - Wave 1

18. Controlling/Costing Actual to Budget Comparison Overhead Project Accounting Cost Center Accounting Profit Center Accounting Rate Application Cost Allocations Activity Based Costing Cost Center Reporting Human Resources Time and Attendance – Civilian/Military Work Schedule Administration Time and Attendance Reporting Purchasing (Goods and Services) Outgoing Government Order MILSTRIP Credit Card Simplified Acquisition Purchase Order Modification Procurement Service Center Fees Material Management Reporting Receipt Management Goods Receipt Goods Return Project Management Project Work Breakdown Structures Project Tracking and Reporting Process Scope - Wave 1 (continued)

19. Controlling/Costing A-11 Budget Development Cost Center Planning/Budgeting Vendor Pay Prompt Pay Check Issue File Asset Management Missing, Lost, Stolen Reporting Capital Leases NAVFAC Asset Reconciliation Human Resources Travel Training Workforce Management Purchasing (Goods and Services) Major Contracts Government Furnished Property Excess Material Shipping Controlled Storage/Project Material (SOM) Project Management Proposal Development Networks Earned Value Reporting Strategic Planning Business Information Warehouse Process Scope- Wave 2

20. Finance (FI) General Ledger Accounts Payable Accounts Receivable Funds Management (IS-PS) Budgeting/Control Controlling (CO) Cost Center Accounting Budgeting/Planning Profit Center Accounting 1Enhancement/Bolt-on Asset Management (AM) Bar-coding (Datavision-Prologix)1 Project Systems (PS) Sales & Distribution (SD) Billing Material Management (MM) Purchasing - Simplified Human Resources (HR) Time and Attendance XYZ Functional Scope- Wave 1

21. Material Management (MM) Complex Contracting (PAI)1 Inventory Management/Warehouse Management (TBD) Bar-coding (Datavision-Prologix) Business Information Warehouse (BW) Data Warehousing Management Reporting Funds Management (IS-PS) Budgeting/Control2 Finance (FI) Accounts Payable2 TBD 1Enhancement/Bolt-0n 2Potential for functionality over & above that included in Wave 1 XYZ Functional Scope - Wave 2 • Controlling (CO) • ABC/M (Oros)1 Material Management (MM) • Complex Contracting (PAI)1 • Inventory Management/Warehouse Management (TBD) • Bar-coding (Datavision-Prologix) Business Information Warehouse (BW) • Data Warehousing • Management Reporting Funds Management (IS-PS) • Budgeting/Control2 Finance (FI) • Accounts Payable2 • TBD 1Enhancement/Bolt-0n 2Potential for functionality over & above that included in Wave 1

22. Organizational Scope

23. SSC-SD XYZ DEV & QAS SSC-SD XYZ Preliminary Production Environment Proliant 1850 2 CPU’s 1GB Mem 18 GB Disk Proliant 1850 2 CPU’s 1GB Mem 18 GB Disk PRD SUN E10K 8 CPU’s 4 GB Mem 120GB disk Raid5 Workplace Proliant 1850 4 CPU’s 2 GB Mem 18GB disk DEV SUN E350 2 CPU’s 2GB Mem 60GB disk QAS SUN E3500 2 CPU’s 2GB Mem 60 GB disk WEB/ITS DEV and QA Systems Workplace DEV and QA Systems 2 NT servers required for Web front end due to security reasons. Ethernet ITS - A Gate Proliant 1850 1 CPU’s 1GB 18 GB Disk Firewall Implementation Team SSC-SD Intranet Users XYZ OSS Application Servers SUN E420s 2/4 CPU’s 4 GB Mem 12 GB disk WEB, ITS- W Gate, Workplace Ethernet Proliant 1850 1 CPU’s 1GB 18 GB Disk Firewall XXX SJ-SDC WAN Ethernet Technical Infrastructure Scope

24. DEF/ CERPS STARS HCM FRS CITIBANK OPAC STARS OBP DONIBIS CDB ERP IFBS TMP DAAS STARS - BI POWER TRACK DCPS MODERN DCPDS Interface Scope

25. SCOPE For Wave 1 of Project Cabrillo, the following interfaces have been identified as of the end of the Project Preparation phase: CITIBANK Bankcard Invoices DAAS MILSTRIP Orders, Order Status DCPS Time & Attendance, Master Employee Record, Gross Pay DEF/CERPS Cash, Monthly Cash Adjustments DONIBIS/CDB General Ledger Summary FRS Billings - Private Party, Private Party Rejects IFBS Interfund (MILSTRIP) Billing MODERN/DCPDS Civilian Employee Data OPAC Billing - All Federal Non-Navy DoD PowerTrack Commercial Transportation Bills STARS-BI Billing – Navy, Billing Rejects, Centralized Master Edit Table (CMET) STARS-HCM Obligations STARS-OBP FADA A/P, Vendor Master, Vendor Payments (Order, Receipt, Invoice or Ready-To-Pay) TMP Funds Authorization, Travel Order, Transportation Interface Scope (continued)

26. Scope G/L Accounts/Accounting Documents Customer Master/Vendor Master, Balances Cost Centers/Internal Orders Cost Elements/Activity Types Statistical Key Figures Funds/Asset Master Asset Retirements/Transfers Work Breakdown Structures Budgets Open Purchase Requisitions/Orders HR Master Project Actual Costs Data Conversion Scope Approach The data conversion business objects identified will be reviewed with respect to the volume of data, number of legacy systems, the quality and complexity of data, and the XYZ transaction requirements to determine the best method of data transfer into the XYZ system. The preferred method for the data conversion activities will be to input the data manually or use a standard XYZ data loading program, if available for the master and transaction data. Every effort will be made to limit the number of custom development objects required for data conversion. It is planned to convert as little historical data as required. A data conversion strategy document will be created to outline the data conversion approach for Project Cabrillo. Data Conversion Scope

27. Scope Define business reports and forms requirements. Perform a gap analysis between these requirements and pre-delivered XYZ reports and forms. Document reports and forms development needs to meet gap requirements. Present business justification for custom requests. Develop design specifications for custom objects. Construct approved reports using XYZ delivered reporting tools, where possible, or ABAP. Test, train, and implement all reports and forms within the framework of the Business Processes. BW is not in scope for Project Cabrillo Wave 1. Existing data will be retained in current legacy systems or data warehouse. Approach Pre-delivered reports and forms must be utilized whenever possible to meet required needs. Primary focus is on consolidating and standardizing all reports. Business reports and forms design must be a company wide solution, not a design exclusively for a specific entity (unless it is a special legal requirement). Standardize business reports and forms across sectors. Development of non-standard reports and forms will be driven by clear business needs and approved by Project Management. Priority will be placed on reports needed to satisfy statutory, legal or critical business requirements. Business Process Owners and Teams must be instrumental in the Business Reports and Forms effort. Business Process Team members will be responsible for obtaining business sectors' approval of report formats, and give complete specifications to the development team. Reports, Data Retention, and Forms Scope

28. Change Management Assures that the SSC-SD community understands the impact and timing of the implementation. The SSC-SD community is segmented into two groups; Internal: Core Project Team, Extended Project Team, (Sponsors, Steering Committee, Advocates/Subject Matter Experts (SMEs), Transition Teams) End Users. External: SPAWARSYSCOM, NAVAIR, NAVSEA, NAVSUP, DFAS, Navy Audit Services and other Navy Warfare Centers. The Change Management activities will address these constituencies as depicted. Communications Internal External Knowledge Transfer Internal (Core Project Team only) Organizational Impact/Role Design Internal End User Training Internal Change Management Scope

29. The training is focused on two groups of users, the Project Team and the End Users. The training approach is role-based to ensure that users understand how to perform the functions associated with their jobs. The courses are designed to train the user population on the overall processes associated with a function and then focuses on specific job roles. Courses: XYZ Overview and Basic Navigation Executive Overview Financials Funds Management Controlling Asset Management Project Systems Sales & Distribution Materials Management Human Resources Reporting Types of Users: Project Team Members End Users Super-users Designated users which provide support as trainers and are the first line of defense for end users once the system is live to answer questions, etc. Heavy (Transactional) Hands-on routine/daily users of the new system. Casual Occasional users of the system and typically serve as back-ups to heavy users. Informational View only users of the system and typically have access to reports. Training Scope

30. Project Development Environment Controls Review of the physical security surrounding the development environment, particularly the planned data center location, and identify risk mitigation measures required to ensure appropriate physical security and controls are in place Design and implementation of security profiles for use by the project team members Development of the SPAWAR SSC XYZ Security Guide, to include standards for controls and security over the basis module, operating system, and database of the development environment Review recommendations on promote to production strategy, copy and refresh strategy, back up and recovery procedures, interface and data conversion procedures, programming control and security standards for both XYZ and Bolt-ons Business Recovery Planning Controls Review recommendations on backup and recovery plan in place for the production environment from a technical perspective, and business recovery plan from a business perspective Business Process Controls Design and implementation of end user security profiles to meet the roles as defined by the benefit and change management team and to support the system administration functions as defined by the technical infrastructure team Development of a segregation of duty matrix for use when assigning roles to jobs Advise on risk mitigation measures where segregation of duties can not be enforced due to the size/ activities of the local organisation Development of a XYZ security administration manual Advise on optimisation and constraints of XYZ control features for the business processes defined in the blueprint phase Design and testing of controls over the business processes in scope of the project Bolt-on Program Controls Assess Bolt-on programs controls and security function Establish requirements in either XYZ or Bolt-ons to meet the required control acceptable to SSC-SD management. Controls and Security Scope

31. Project Strategy • Technical Architecture Strategy • Change Management Strategy • Training Strategy • Test and Evaluation Strategy • Implementation and Rollout Strategy • Development Strategy The following sections summarize the specific strategies devised to execute the major sections of Project Cabrillo.

32. Technical Architecture Approach The objective of the Technical Architecture Strategy is to minimize risk and ensure that stable development, testing, training and production environments are built. The Technical Architecture Strategy approaches this objective with two means. First, it defines which clients will be created and refreshed throughout the lifecycle of the project. This activity serves to provide configuration and data that is needed to support the testing and training requirements of the project only for the duration of their use. Second, it defines the method of transporting change requests between clients and systems. These activities build the environments with required configuration and development changes, and minimize the risk of unauthorized or unrecorded changes. System Architecture The System Architecture consists of all Systems and their respective client architecture that access a common transport directory. The Cabrillo Project at SSD-SC will utilize a three-system architecture, which consists of the following Systems: Development (DEV) Quality Assurance and Training (QAS) Production (PRD). Landscape The landscape changes during the various project activities - Prototyping and Unit Testing; Integration Testing and Training, and Go-Live. Prototyping and Unit Testing are performed in the development system. Integration testing and training expands to the quality assurance and training system. For Go-Live the production system is built in the same manner as the QAS system. Technical Architecture Strategy

33. Promote to Production Strategy All changes (Development, Configuration, and OSS Notes) should be released from DEV after successful unit testing. In order to have the requested change released, the task owner should submit the request for approval. A quality review will check all naming conventions and ensure testing and user requirements are met. Once approved, the approver then releases the request from. At a predetermined time, the Infrastructure Team will import the changes to the QAS system. After final testing of the QAS system, the transports are then approved for import into Production. As the PRD buffer should not be manipulated in any way, not approving a transport request indicates further work is to be done in the DEV system and tested in QAS. Once acceptance of the QAS system is received, all transports in the PRD buffer are imported together. Technical Architecture Strategy (continued)

34. Communications Builds awareness and commitment in the organization to the new system and business process changes. Successful communications employs “two-way”flow of information that is cascaded throughout all levels of the organization. This ensures that all stakeholders have consistent and timely information about their roles, responsibilities and project activities which will minimize the anxiety associated with large scale systems implementations. Knowledge Transfer Ensures that knowledge and skills are effectively transferred to the SSC-SD core project team members, supporting a successful enterprise system implementation. The goal of Knowledge Transfer will be to increase the SSC -SD team member’s motivation through learning and skills development so that the organization’s ownership of the XXX system is complete and it will be well positioned to conduct future XXX initiatives. Organizational Impact/Role Design Ensures that specific job roles and processes that are created in the new environment are documented and mapped to specific legacy job roles. This activity links the conceptual system framework to the actual end users in the organization, and forms the basis for building process scripts, training materials, and end users lists which in turn are used to build security profiles and to schedule end user training classes. End User Training Provides end users a chance to learn both the mechanics of the new system and the new business processes that will be used to conduct their jobs. To assure the highest degree of proficiency on the new system, the majority of training will be instructor-led and there will be an emphasis on demonstrations and hands-on exercises. Change Management Strategy

35. During the SSC-SD Project XYZ implementation, training must play a critical role to transfer knowledge effectively so that the staff can make the transition to the new system and processes. The SSC-SD Training consists of the following key deliverables: Instructor-Led Training Project Team Training Pilot Training Train-The-Trainer End User Training Training Documentation Concept Slides Process Maps Work Instructions Exercises Job Aids Training Infrastructure Training Client (Database) Knowledge Warehouse (Electronic Performance Support System) Training Logistics Training Scheduling Training Facilities Training Equipment Training Evaluations Support Training Help Desk Frequently asked Questions and Answers Training Strategy

36. Test Approach The overall objective of performing various levels of testing at SSC-SD is to ensure the XYZ system meets the ‘To Be’ business requirements as documented and configured during the Realization stage. This testing includes functionality of the XYZ system; related processes; integration with other systems and business partners; XYZ system security based upon identified business roles and responsibilities; the technical production environment; and the testing of other tools or systems to be used in conjunction with the XYZ system. Test Process System testing will include five scenarios: Unit/Scenario Testing,Integration Testing, Security Testing, User Acceptance Testing and Technical Infrastructure Testing. Testing will range from business processes (Sales Order Processing, Purchasing, Finance, etc.) to technical (Security Administration, Operations Support, Database Admin, Internal Disaster Recovery, etc.) Test Cycles Test cycles will be defined by the Integration Manager and confirmed by the Integration Test team. These test cycles will define a group of end-to-end businesses processes, and will attempt to simulate the production environment processing. Test Error Handling & Resolution A Test Problem Report (TPR) will be created where the actual test result differs from the expected result. This document will be used by the Integration Team as a starting point in determining the source of the reported error. When the TPR is created, it will be assigned to the team lead in the functional area where the problem occurred. Each team lead will be responsible for assigning the TPR to the appropriate person who needs to resolve the TPR. TPR’s encountered during the execution of the test plan should be identified next to the appropriate test condition in the Integration Test plan. TPR’s will be tracked to final resolution by the Integration Team. Test & Evaluation Strategy

37. User Acceptance Testing The User Acceptance Test provides the means necessary to ensure that the flow of systems, communications and manual processes are in place prior to going productive. This step of the System Test adds an additional check point by emphasizing the higher-level flow of the transactions executed rather than the technical processing aspects of the systems and business processing requirements. The User Acceptance Test will simulate the end-to-end business processes that need to be validated or executed by the Process Owners before they can approve the system for go-live. System Delivery The final phase of the User Acceptance Test is Process Owner Review and Signoff. A critical requirement of the User Acceptance Test is availability of Process Owners or their designated representative to execute the test. During this testing phase, the Process Owners will execute the Test Cycles for the appropriate stakeholders to demonstrate the successful execution of the technical results, business requirements, and organizational flow constructed to support the SSC-SD business. Upon successful completion of the User Acceptance Test, the Process Owner is responsible for formal signoff and the system will be deemed ready for Go-Live. Test & Evaluation Strategy (continued)

38. Implementation and Roll-Out Approach Recommendation SSC-SD’s market forces, implementation timeline and technical infrastructure requirements indicated the best approach was a Full Scope or “Big Bang” XYZ implementation approach. This Full Scope approach is one where all of the SSC-SD business processes are brought up or “Go-Live” with all planned functionality at once. SSC-SD XYZ System Landscape A three-system landscape, as described in the Technical Architecture Strategy, will provide SSC-SD with an isolated development, test, training and production environment. Cutover Approach After extensive and rigorous testing of the system, conversions, and all interfaces, a hard cut-over to the new system is planned. At critical milestones during the project, Project Management, Project Sponsors and Steering Committee will review readiness for implementation. At any time during this process, a go/no-go decision may be made based on project team and system readiness. Implementation and Roll-Out Strategy Potential XYZ Implementation Approaches

39. Documentation Approach The Interface Detailed Definition (IDD), Data Conversion Detailed Definition (DCDD), Report Detailed Definition (RDD), and Enhancement Detailed Definition (EDD) documents in the Ascendant XYZ Toolset will be used as a repository to facilitate and document each interface, conversion, report/form, enhancement design, functional requirements, program code, and testing. Development Process Interfaces, Conversions, Reports/Forms and Enhancements will require similar development techniques. IDD and DCDD documents will be prepared by the functional teams. These documents will serve as the basis for developing technical specifications and consequently the objects which will perform the interface or the conversion. The development of the object from technical specifications through the unit test will be done by the San Jose Solution Delivery Center. Interface/Conversion Controls Although this section specifically speaks to Interfaces, very similar controls will exist for Conversions. Automated, outbound interfaces sending data to external systems will use logic to incorporate record counts, control totals, date/time stamps, initializing records and/or trailing records as required by the target system. This processing will be used to check data completeness, integrity and redundancy. Error handling will also be performed by the target system. Error Handling An audit report is to be produced by all interface and conversion programs. Details on what the audit report should include will be outlined in the Interface Detailed Definition (IDD) document and the Data Conversion Detailed Definition (DCDD). Leverage Every effort will be made to leverage any existing technology. Logicon-INRI has worked with some of the external systems with which SSC-SD will need to interface. It may be possible to leverage any work they have already completed. Their knowledge and contact information will also be leveraged. Development Strategy

40. Project Management • Plan of Action and Milestones for Navy Pilots • Project Cabrillo Work Plan • Ascendant XYZ Project Methodology • Risk Management Plan • Issue Management Plan • Scope Management Plan • Project Planning and Monitoring

41. Plan of Action and Milestones - Navy Pilots

42. Final Preparation Go Live Project Preparation Project Cabrillo Workplan -------------Realization------------------ Blueprint Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Kickoff Detailed Process Design Configure/Prototype/Test Set-up Production Environment Install QA System Install Dev. System Data Conversion Project Charter Develop/Test Conversion Programs Design Specs -Interface -Conversion -Reports -Forms Cutover Plan Detailed Project Scope Develop/Test Interface Programs Production Support Plan Develop/Test Report Programs Procedures Create End User Training Train End Users Team Trng. #1 Team Trng. #2 Integration System Test Stress/Volume Testing GO LIVE

43. Project Cabrillo Workplan (continued)

44. Project Cabrillo Workplan (continued)

45. The Ascendant XYZ project methodology consists of seven project phases, including five of those found in XYZ's Accelerated XYZ (AXYZ) methodology. Following is a brief purpose for each project phase: Evaluation (Phase 0) - Business case and XXX proposal Project Preparation (Phase 1) – Project Kick-off and Project Charter developed. Business Blueprint (Phase 2) – Detailed technical, process, development, and organizational scope definitions and requirements finalized. Realization (Phase 3) – System configured, development completed and most testing accomplished. Final Preparation (Phase 4) – Readiness to go-live; users trained, data loaded, production system initialised. Go-Live (Phase 5) -Stable system, project team disbanded. Sustain (Phase 6) - Benefits realized, post-implementation review, system tuning and upgrades The Ascendant XYZ Toolset is being used for all project deliverables and project management documentation. It is a web-based repository with search and reporting capability, including detailed methodology, project accelerators, and documentation templates. Phase 0 Phase 5 Phase 6 Phase 2 Phase 3 Phase 1 Phase 4 People Process Knowledge Technology Ascendant XYZ Project Methodology

46. Risk Analysis Analysis identifies potential problem areas, estimates chance of loss, and evaluates consequences. Project risks have been classified into seven categories and summarized in the Risk Management Plan: Leadership Business Project Resource Technology Change Leadership Training and Documentation Risks have been evaluated for probability of occurrence (Likely, Moderate or Unlikely), impact to the project, and risk level (High, Medium or Low). Risk Management Management responds to the analyzed risks and plans methods to control risks through: Reduction or protection Contingencies to respond to risks that occur Monitoring of actual risks Execution of plans Mitigation strategies are defined for each risk. Project Management is responsible for monitoring each risk, continually reassessing the probability it will occur. As risks are realized, Project Management is tasked with monitoring and executing the prescribed mitigating actions. Risk Management Plan In complex projects such as Project Cabrillo, a degree of uncertainty exists that creates both risks and opportunities. Capturing the opportunities and mitigating the risks are the primary goals of the project management team. Project Management must be proactive in identifying potential risks and ensuring the appropriate mitigating actions are taken before the cost, schedule and quality of deliverables are impacted. Risk is identified as anything that threatens the achievement of project objectives. The project will use a 2-step risk management process as shown below, with Step 1 addressing Risk Analysis and Step 2 covering Risk Management.

47. Three key elements determine how issues will be handled during the resolution process: Priority (High, Medium, Low) is defined as the impact to the project cost or schedule should the issue go unresolved. Criticality (High, Medium, Low) indicates the time sensitivity of getting a resolution; high criticality issues must be resolved within 48 hours or less. Level (Team, Project, Steering Committee) defines the highest level of management that will need to be engaged to facilitate a resolution. Not all high priority or high criticality issues will require senior management involvement. Conversely, certain low priority or low criticality issues may require involvement of the Project Sponsor, senior SSC-SD executives or external agencies to accomplish resolution. The Issue Management process consists of the following basic steps: Raising Issues - The identification and recording of issues in the Ascendant XYZ Toolset Issue Validation - Validation of the appropriate level and schedule for resolution of the issue Issue Escalation - Involvement of the appropriate executives and external parties to accomplish resolution Issue Resolution - The recording of the resolution of an issue Issue Reporting - The reporting of the status of recorded issues Issue Review and Sign-off - Review of the outstanding issues by the Project Management team and closure of resolved issues Issue Management Plan The purpose of this plan is to provide a formal structure for the recording and resolution of issues raised throughout Project Cabrillo. An issue is defined as any point impacting the solution delivery that requires cross-group formal involvement and/or an SSC-SD policy or business rule decision. Managing issues is an essential responsibility of project management and is fundamental to the success of Project Cabrillo implementation. Issues will be documented and tracked using the Issue (ISS) form in the Ascendant XYZ Toolset.

48. Requested scope changes must be submitted on an SCR form to Project Management after team lead review. Justification for the change must be clearly explained, and resource impact must be estimated. The Project Manager will assess the cost, along with any additional resources required, and schedule impacts of incorporating this change in the development and implementation schedule. All requests will be considered, but only essential scope additions will be approved. As an example, a change SSC-SD may need to satisfy statutory reporting requirements would be considered essential. Scope Management Plan During the course of the project, requests for additional process or system functionality will occur. Changes may have an impact on scope and thus may effect project duration, resources required and project costs. A formal Scope Management Process is used to document change requests, to present them for formal written approval, and to manage the requests. All requests are documented and tracked on a Scope Change Request (SCR) form, entered in the Ascendant XYZ Toolset. • The Project Manager will be responsible to monitor pending SCR’s through their life cycle for approval or rejection. • The Project Charter is the basis for the pilot scope definition. The Project Manager, Program Manager, Project Sponsor, and Steering Committee, as necessary, must agree on all inclusions orexclusions.

49. Project Workplan The Ascendant XYZ-based Project Workplan will be used to track cost and schedule for the project. The methodology provides a proven and comprehensive approach to implementing XYZ, and the Workplan contains Work Breakdown Structures necessary to monitor detailed tasks. Weekly Project Status Status will be tracked against WBS task level on a weekly basis, through update of the Project Workplan and preparation of team and project-level status reports. Weekly Project Review Meetings are held with the management team to review progress-to-date, resolve cross-team issues and address project procedural and policy decisions as they may be required. Steering Committee Steering Committee meetings will be held monthly and at critical points as needed during the project to facilitate resolution of major issues. The Steering Committee will conduct end of phase reviews and acknowledge readiness to proceed to the next phase of work. Earned Value Analysis (EVA) An Earned Value Analysis (EVA) approach will be used for measuring progress in the projects and program. The Project Management team will routinely compare cost to budget and schedule variances and completion of deliverables against the plan. Project Planning and Monitoring

50. Deliverable Acceptance A clearly defined set of deliverables for each phase is agreed to prior to start, and deliverable documentation is reviewed across teams, where appropriate, and approved by Project Management and SSC-SD Contracts representative. All project deliverables are maintained in the Ascendant XYZ Toolset, as are Project Workplan, status reports and other work products. Project Planning and Monitoring (continued) Quality Reviews • Various quality reviews will be conducted during the course of the project, as documented in the Quality Management plan. They include: • PricewaterhouseCoopers Project Quality and Risk Management reviews. • System development procedure and quality reviews conducted by the PricewaterhouseCoopers Solution Delivery Center. • Change management and training quality reviews conducted by the PricewaterhouseCoopers Center for Performance Improvement. • Gold Team reviews consisting of senior PricewaterhouseCoopers and XYZ consultants to confirm best practice process design and troubleshoot XYZ gaps.