SPAWAR Systems Center San Diego Enterprise Resource Planning Project Charter - PowerPoint PPT Presentation

Loading...

PPT – SPAWAR Systems Center San Diego Enterprise Resource Planning Project Charter PowerPoint presentation | free to view - id: 12cefe-Yjg0N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

SPAWAR Systems Center San Diego Enterprise Resource Planning Project Charter

Description:

ERP technology will enable SSC-SD to have the ability and flexibility to ... SSC-SD XYZ Preliminary Production Environment. 2 NT servers required. for Web front ... – PowerPoint PPT presentation

Number of Views:684
Avg rating:3.0/5.0
Slides: 76
Provided by: eitoo
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com