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 Charter Table of Contents

• 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

4
Project Charter Table of Contents (continued)

• 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

5
Project Overview

• Executive Summary
• Project Objectives
• Project Mission Statement
• Critical Success Factors
• Concept of Operations

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
  XYZs 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 Objectives

• 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 RDTE 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.

8
Project Mission Statement

• 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.

9
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.

• Decision Making
• Project Management
• People/Teams
• Process
• Organization
• Training
• Systems
• Sustaining Support

10
Critical Success Factors

• 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.

11
Critical Success Factors

• 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

12
Critical Success Factors

• 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.

13
Critical Success Factors

• Systems
• Business process will utilize XYZs 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.
  

14
Concept of Operations Overview

• 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.

15
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

• 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.

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
Process Scope - Wave 1

• 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

18
Process Scope - Wave 1 (continued)

• 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

19
Process Scope - Wave 2

• 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

20
XYZ Functional Scope - Wave 1

• 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

21
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

• 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
Technical Infrastructure Scope
24
Interface Scope
25
Interface Scope (continued)

• 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

26
Data Conversion Scope

• 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.

27
Reports, Data Retention, and Forms Scope

• 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.

28
Change Management Scope

• 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

29
Training Scope

• 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.

30
Controls and Security Scope

• 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.

31
Project Strategy
The following sections summarize the specific
strategies devised to execute the major sections
of Project Cabrillo.

• Technical Architecture Strategy
• Change Management Strategy
• Training Strategy
• Test and Evaluation Strategy
• Implementation and Rollout Strategy
• Development Strategy

32
Technical Architecture Strategy

• 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.

33
Technical Architecture Strategy (continued)

• 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.

34
Change Management Strategy

• Communications
• Builds awareness and commitment in the
  organization to the new system and business
  process changes. Successful communications
  employs two-wayflow 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
  members motivation through learning and skills
  development so that the organizations 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.

35
Training Strategy

• 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

36
Test Evaluation Strategy

• 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.
  TPRs encountered during the execution of the
  test plan should be identified next to the
  appropriate test condition in the Integration
  Test plan. TPRs will be tracked to final
  resolution by the Integration Team.

37
Test Evaluation Strategy (continued)

• 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.

38
Implementation and Roll-Out Strategy

• Implementation and Roll-Out Approach
  Recommendation
• SSC-SDs 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.

Potential XYZ Implementation Approaches
39
Development Strategy

• 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.

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
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 -Form
s
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
Ascendant XYZ Project Methodology

• 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.

46
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.

• 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.

47
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.

• 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

• 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.

48
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.

• 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.

• The Project Manager will be responsible to
  monitor pending SCRs 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 or
  exclusions.

49
Project Planning and Monitoring

• 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 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.

50
Project Planning and Monitoring (continued)

• 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.

• 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.

51
Project Organization

• Navy ERP Pilot Organization
• SSC San Diego Organization
• Team Roles and Responsibilities

52
Navy ERP Pilot Organization
53
Program Organization
Steering Committee R. Kolb Capt. E. Valdes R.
Smith C. Keeney R. Pierson B. Frye K. Leung R.
Luby (XXX) R. Burnett (XXX) R. Neubauer (XXX)
Project Sponsor R. Kolb/H.Porter
Program Management R. Pierson R. Burnett (XXX) R.
Neubauer (XXX)
Change Management R. Volker B. Convery (XXX)
Resource Manager D. Nienow-Smith
Project Management M. Nguyen K. Hanrahan (XXX)
Other Activities DFAS, NAVAUD, NSWC, NAVSUP,
NAVDEP, NAWC,
Business Process Teams R. Frye, R. Laverty D.
Shanahan, K. Halbe, Ken Baker (XXX)
Technical Team (Sys. Engrg.) D. Hamaguchi J.
Tello (XXX)
54
Program Administrative Staff
Program/Project Management
Kevin Adams (XXX) Cost and Schedule Analyst
Debbie Nienow-Smith Resource Manager
(Vacant 10/18) Administrative Asst.
Carla McManus (XXX) Project Adm. Assistant
Jane Nunez Financial Sys. Help Desk
Evita Gonzalez Student Aid
Ed Agunos Student Aid
Greg Volker Student Aid
Fabiola Salazar Student Aid
55
Business Process Team
56
Business Process Team
Business Process Lead Bob Frye/Rich Laverty Ken
Baker/Kevin Halbe/Dave Shanahan (XXX)
HR Management Team Ruth Gallegos Bill Heisch (XXX)
Material Management Team Cherri Broyles James
Chung (XXX)
Project Management Team Joe Weber Scott Ramsay
(XXX)
Dan Lumpkins (A) Henry Porter (NSWC-C) Zack
Georgian (XXX) Steve Benvenuto (XYZ) Nancy Vorce
(SME) Debbie Nienow-Smith Athanison Monroe TBD
(SSC)
Andy Jung (SME) Jennifer Alagna (XXX) Ben Raihani
(XXX)
Tony Amadeo (OSEC) David Miranda TBD -
(SSC) Thad Nagel (XXX)
57
Technical Team
Technical Team Doug Hamaguchi/Juan Tello (XXX)
Testing Dave Steber Juan Tello (XXX)
Tech Infrastructure Horace Stanton Brian Glover
(XXX)
Application Development Scott Fagergren Nic Lira
(XXX)
Help Desk Mel Moy TBD (XXX)
Security Dave Steber Greg Granger (XXX)
58
Change Management Team
59
Extended Project Team
Controlling Team
Finance Team
Asset Mgmt. Team
Funds Mgmt. Team
Dallas Cartwright (SME) Susen Wen (SME) Andy
Chevrie (SME) Bruce Schuler (DFAS-C) Ola Jackson
(NADEP-C)
Bruce Baraw (SPAWAR HQ)
Jim Straus (A) Barbara Scuito (SME) Gabe Haduch
(SME)
Liz Caudell (SME) Linda Turnbow (DFAS-C) Linda
Modica (A)
60
Extended Project Team
61
Team Roles and Responsibilities
Team Roles have been identified and are listed
below. They are discussed in greater detail in
Appendix A.

• Program Manager
• Project Manager
• Business Process Team Lead
• Business Process Team Member
• Change Management Team Lead
• Change Management Team Member
• Training Team Lead
• Training Team Member
• Technical Infrastructure Lead
• Technical Infrastructure Team Member

• System Development Team Lead
• System Development Team Member
• ERP System Security Lead
• Integration Lead
• Sponsors
• Steering Committee Member
• Advocate
• Subject Matter Expert
• Transition Manager
• Transition Leader
• Contributing Member

62
Assumptions

• The project team will be supported by the Project
  Sponsor and Steering Committee.
• Project management will be available to address
  and resolve issues in a timely manner.
• Project teams will be empowered to design the
  To-Be business processes for SPAWAR Systems
  Center - San Diego.
• Dedicated full-time SSC-SD resources will be
  assigned for the life of the project, and will
  not have responsibility for work outside the
  scope of the project.
• Development of work products and deliverables
  will be the shared responsibility of SSC-SD and
  XXX team members.
• Only standard XYZ functionality and defined
  bolt-ons will be used to support to-be business
  processes. There will be no customization of the
  XYZ source code.
• SSC-SD, PricewaterhouseCoopers and XYZ subject
  matter experts from outside the core team will be
  needed on a part-time basis to assist with design
  or troubleshooting activities.

• The project scope outlined in this document is
  based on information disclosed during team
  discussions and process reviews held during Phase
  1. This scope will not change unless mutually
  agreed upon by SSC-SD and PricewaterhouseCoopers.
• The Project Cabrillo implementation will be
  completed on XYZ Release 4.6B and JFMIP release
  4.61B, and XYZ will provide as needed any
  additional functionality to demonstrate JFMIP
  requirements.
• The technical architecture and procedures are
  compliant with known security requirements.
• Changes to the technical environment will be made
  only with the mutual agreement of SSC-SD and
  PricewaterhouseCoopers.
• Stress testing will be conducted only as may be
  required for transaction and interface program
  volume testing.
• Any cleansing of legacy data required will be the
  responsibility of SSC-SD personnel who are not
  full-time project team members.

63
Appendices

• A. Team Roles and Responsibilities
• B. Project Work Plans
• C. Concept of Operations

64
Appendix ATeam Roles and Responsibilities

• Program Manager
• Ultimate owner of the project with
  decision-making power
• Member and facilitator of Steering Committee
• Maintains final authority to set priorities,
  approve scope, and settle organization-wide
  issues, define budget
• Promotes the project throughout the SSC-SD
  organization
• Represents the executive group and project to
  external stakeholders (e.g. Other Navy Pilots)

• Project Manager
• Provides methodology for project implementation
  approach
• Defines project deliverables and critical target
  dates
• Assists in defining project scope and objectives
• Develops and maintains project work plan and
  budget
• Leads project status meetings
• Reports issues and weekly progress against
  schedule to Steering Committee and executive
  management
• Acquires and assigns resources required for the
  project, including support / subject matter
  experts
• Manages resolution of issues and escalate as
  appropriate
• Proactively anticipate and manage areas of
  program risk
• Prioritizes and assigns work to teams
• Motivates, manages and evaluates team leads

65
Team Roles and Responsibilities

• Business Process Team Lead
• Develops and maintains team work plan
• Reports issues and weekly progress against
  schedule to project mgmt.
• Leads development of "to be" processes and system
  redesign
• Develops, communicates and gains buy-in for
  global data standards (e.g. customer, vendor,
  accounts)
• Coordinates resources required for the team,
  including support / subject matter experts
• Facilitates intra- and inter- team integration
• Leads team status meetings
• Drives resolution of issues
• Identifies and controls areas of risk
• Prioritizes and assigns work to staff
• Motivates, manages and evaluates team members

• Business Process Team Member
• Designs new business processes and validates
  design assumptions
• Provides business process or technical expertise
  as a subject matter expert
• Configures, prototypes tests new processes in
  XYZ
• Develops documentation for the new system
• Coordinates user system testing and validation
• Identifies XYZ gaps and provides resolution
  alternatives
• Establishes two way communications with subject
  matter experts and assists Change Mgmt. team to
  identify impact of process/system change
• Supports procedure and training material
  development, and provides post-implementation
  user support.

66
Team Roles and Responsibilities

• Change Management Team Lead
• Develops Knowledge Transfer (KT) strategy and
  work plan
• Leads effort to assess KT requirements, develop
  learning objectives and implement knowledge
  management program
• Develops Communications strategy and work plan
• Ensures two-way flow of communication on project
  information from project team to SSC-SD audience
  and external "stakeholder" community
• Develops Organizational Impact strategy and work
  plan
• Defines plans for building executive commitment
  and dealing with organizational changes or
  resistance

• Change Management Team Member
• Works with business process team members and
  "super" users to drive business process
  transformation
• Assesses knowledge transfer requirements,
  develops learning plan and designs knowledge
  management program
• Designs cascading communications tools and
  mechanisms
• Ensures two-way flow of communication on project
  information internally with project team and
  SSC-SD, and with the external stakeholder
  community
• Leads organization development of assigned area,
  including organizational design, job redesign,
  performance metrics realignment
• Works with end user community (through Transition
  Team) to ensure acceptance and adoption of
  envisioned organization

67
Team Roles and Responsibilities

• Training Team Lead
• Develops project team and end user training plan
• Facilitates project team training
• Works with business process teams to identify
  critical user training scenarios
• Works with process owners to assess overall
  training needs
• Leads development of best-fit training strategy
• Guides training team members in development of
  training curriculum and materials
• Reviews and approves training curriculum and
  materials
• Works with Change Management team to communicate
  training approach to the organization at-large

• Training Team Member
• Works with business process team members and
  super users to create end user training strategy
• Develops the training database
• Identifies required courses and designs
  curriculum
• Develops training materials and course exercis