Ods Project Plan V0

ODS-Data Synchronization Project Plan & Resource Requirement

ODS-Data Synchronization Project Plan & Resource Requirement: Phase I RELIANCE INFOCOMM

Document Information Project Name:

ODS – Data Synchronization

Project Manager:

Document Version No:

0.3

FocusPM Phase:

Document Version Date:

26 Oct. 04

Prepared By:

Preparation Date:

04 Oct. 04

Reviewed By:

Review Date:

Quality Review Method:

Distribution List From

To

Action*

Date

Phone/Fax

26/10/04

30385621

Due Date

Phone/Fax

Review

* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify) Version History Ver. No.

Ver. Date

0.1

4/10/04

Changed Plan, Assumptions / Constraints, Resource List

0.2

13/10/04

Changed Deployment Infrastructure

0.3

26/10/04

Changed Execution and Project plan, Added HP related details in Project Plan

Project Plan – ODS

Revised By

Description

File name

Page 2 of 49

INDEX 1.Purpose of the Document.................................................................................4 2.Purpose of the ODS...........................................................................................4 3.Users of ODS......................................................................................................4 4.Assumptions and Constraints (RIC ODS Specific)........................................7 5.ODS Program Model..........................................................................................8 6.Execution Plan.................................................................................................10 7.ODS Approach..................................................................................................11 7.1.Data Model for ODS....................................................................................11 7.2.Synchronization ..........................................................................................12 7.3.Initial Load ..................................................................................................13 7.4.ODS Development and Implementation.....................................................14 8.Test Strategy.....................................................................................................15 10.Information in ODS........................................................................................18 11.Source Systems for ODS..............................................................................18 14.ODS Project Plan...........................................................................................28 15.Resource Requirements...............................................................................32 16.Software & Hardware Requirements...........................................................33 17.Risk Mitigation (Project Management Specific).........................................34 18.Constraints (Project Management Specific)...............................................35

Project Plan – ODS

Page 3 of 49

1. Purpose of the Document Purpose of the document is to finalize project plan and resource requirements for the ODS project. 2. Purpose of the ODS The purpose of the ODS is to integrate data for Wireless & Wireline customers and provide single view of customer. This data needs to be synchronized with the owner sources. ODS will become the reference point for synchronization and synchronizing systems with each other will be done on the basis of desynchronization reports generated by ODS. The business purpose of the ODS is to:  Integrate data and provide a single view of customer  Synchronize actions to block all leakage points that makes service failure or revenue leakage  To assure that there are no leakages due to back end operations that are modifying parameters that affect revenue or service  Synchronize all service and revenue affecting parameters  Continue to improve visibility and lead-time (detection, propagation and reaction) of synchronization. ODS will provide:     

Real time data integration to the extent possible on TIBCO Synchronize data with source systems Generate actionable Synchronization Status Get Synchronized Single View of Customer Query, Real time Dashboards, Rules Engine triggers & Reporting

3. Users of ODS The users of the ODS are: − Operations Managers Project Plan – ODS

Page 4 of 49

− Revenue Assurance − Back Office Operations

Revenue assurance will be the primary user of the ODS. ODS will be used by RA to detect causes of revenue leakages and service failures. Some of the causes that can be reported on are:    

Order and Fulfillment Service Status de-synchronization Back-end processes Initial period of customer acquisition issues

Other operations will be the secondary users of ODS as they will be able to use the intelligence generated by RA and act on causes of revenue loss.  Recovery of revenue losing de-synchronization can be affected by the information generated by RA. Views The RA users of ODS will get following views: CAF – Logged in but not fulfilled CAF – Not OTAFed Amount paid and Payable not equal report at the time of customer acquisition Address Verification (AV) Status and its aging Monitor ILD/NLD activation Report Name changes Track Address change and new AV status Adjustments tracking based on: o First 30 days of customer o Based on Value o Based on User ID Trouble Tickets generated with 30 days of fulfillment First bill generation and tracking User ID based action tracking for adjustments Voucher reconciliation status The data cleansing during the initial loading of the ODS, to ensure that ODS has only synchronized records, will lead to the RA getting the information on any mismatches existing in the systems. Any mismatch will lead to ODS rejecting the data for the want of correct integrated information. Project Plan – ODS

Page 5 of 49

For example, if multiple instances of CAF Nos exist in different systems, ODS will provide a report on the multiplicity of CAF’s which will need to be corrected before the data can be loaded in t ODS. Also, for a customer, if the data is different in different systems, it will be reported and synchronization regain will be done before the data can be loaded in the ODS. Dashboards Real time dashboards will be available for RA to be able to track the information in real time, if available from source systems. In case the real time information is not available, views will have the latency of one day. These dashboards can be drilled down to check the information to the lowest detail. For example, the Payment amount for the day can be tracked against the target for the day and the dashboard can be drilled down to get the payment status of Circles and OTC’s. Reporting Standard Reporting will be done based on the requirement of users of ODS. Actionable business rules engine may be developed later to alert the users of certain actions so that corrective steps might be initiated. For example, if the business rule defines that any name change activity should be brought to notice of RA team, email notifications can be sent to the responsible person on a customer name change (MACD) on a real time basis. Benefits  Ability to get single view of customer  Actionable status on revenue leakage and service failure to RA  Actionable status on de-synchronization of customer related attributes  Reporting load borne by ODS  Ability to report and respond to triggering events

Project Plan – ODS

Page 6 of 49

4. Assumptions and Constraints (RIC ODS Specific) 1. The extent of de-synchronization in RIC systems is not known. This will have impact on the initial load as de-sync data will need to be synchronized before loading in ODS. 2. The backend processes currently used in RIC for changing customer data are not standardized. The non-standard processes will cause desynchronization to occur in the system. This would put additional load on all the systems to synchronize again. 3. ODS is primarily dependent on the TIB data exchange mechanism. It is assumed that the certified messages are not lost and hence the exchange data loss due to outages is not present. 4. The synchronization process cannot be achieved in isolation by ODS. All the operational systems in RIC will be aware of the ODS and will change data from backend processes only after ODS has been informed. This will ensure that the ODS team is able to manage synchronization with the source and other systems. 5. It is assumed that the NWA architecture will be in production at the time of ODS going live. 6. ODS architecture is based on the NWA and will not support pre-NWA architecture. The data will be received from Clarify and not from RECON. 7. It is assumed that data in the source systems would have been migrated to NWA data models before ODS goes into production. It will not be possible to populate data that is in different formats in to single ODS data model. For example, it is assumed that enterprise wireless customers will have migrated to the new data model with GAN, CAN and BAN. 8. It is assumed that TIBCO architecture will be able to support the real time data requirements of ODS. In case real time data requirements are not fulfilled by TIBCO architecture, ETL process will be employed. The latency of this data will be dependent on extract window with source. Usually it will be once a day feed. ETL process will need system availability to extract data. 9. It is assumed that current data models and data dictionary for source systems will be available to design team during the design phase. The non-availability will affect the schedule negatively. Project Plan – ODS

Page 7 of 49

10. It is assumed that the required business rules have been implemented at the source systems and ODS will be applying only data integrity rules on the data being received from source systems. 11. DSS data model, reporting requirements, etc. are not known at this time and are not being considered. 12. Sales Channel definition will be defined in ODS data model but will not be implemented in this phase of ODS. 13. The source systems to be synchronized will be required to give full nightly feed of required data to determine de-synchronization in the initial phases of deployment. 14. EAI will be able to provide the message status to ODS to keep track of synchronization in target systems. 15. It is assumed that the de-synchronization status reported by ODS will lead to the removal of cause of de-synchronization in source systems. If the resynchronization strategy is not in place the de-synchronization report will have little meaning. The process of re-synchronization will be defined by all systems together. 5. ODS Program Model The ODS program model represents the overall program management activity for building ODS.

Project Plan – ODS

Page 8 of 49

Fig.1 ODS Program Model

Program Management

Business Analysis Project Management Review Current Data being exchanged Data & Process Flow Diagrams Identify Data not being exchanged but required in ODS. Define Business Meta Data Define Owner of Data, Window & Access of Owner Systems Project planning

Release Management

Project Plan – ODS Phase 1

Program Planning and Management Program Documentation and Control Budget Monitoring

Database Design

Create Logical Data Model (ERD) Synchronization Tracking Data Model Physical Data Modeling CIM Mapping Technical Metadata

S/W Program Design

ODS Development & Testing

TIBCO Process TIBCO Adapter/IM Application (For ODS) ETL Synchronization Design Error Handling Outages Recovery Reports & Dashboard Design

ETL and TIBCO Process Development and modification Adapter Modification and Development Sync Process Development Testing Deployment Initial Data Load Production

Prioritization Project Planning and Tracking Post Activity Review

Page 9 of 49

Infrastructure/ Production Support

Infrastructure hardware and software Database Implementation support Application support Reporting & Query Management

6. Execution Plan ODS plan is to integrate the current Wireless & Wireline data at one place to get one view of customer. The proposed Execution Plan is: Functional & Integration Architecture Scope 1 Wireless (Corporate & Consumers) Scope 2 Enterprise Wireline Scope 3 Business Rules, Triggers, Re-Inserts (De-Duplication, Householding, etc.) Deployment Architecture Final plan to be provided by HP HP Proposed plan is as follows. 1. Project kickoff 2. Gather and document Technical Requirements 3. Gather and document Exception Processing Requirements 4. Gather and document info (interfaces, protocols used, message formats) on pre-identified contributing applications 5. Development system procured and configured 6. Solution High Level Design 7. NonStop ZLE Data Store – Logical Design 8. NonStop ZLE Data Store – Physical Design 9. RTID Customization (metadata definitions, subscription service development) 10. Rules Definition and RE Implementation 11. Interface Simulator Development 12. Test Library Development 13. TIBCO JMS Configuration 14. NonStop ZLEDS Load complete for test Environments 15. Unit and Integration testing using simulators and test data 16. Development 17. Integration Test Environment setup at Abc Inc 18. Integration Testing using test Abc Inc systems and data 19. Test Environment setup for Technical and Functional Acceptance Project Plan – ODS Phase 1

Page 10 of 49

20. Technical and Functional Acceptance using customer data and test systems 21. TOI to Technical Groups 22. Go Live Decision 23. Controlled Production Environment Preparation including loading customer data 24. 30-day Controlled Production Run 25. Controlled Production Run Assessment 26. Production Deployment Final 7. ODS Approach The ODS project consists of following activities:

7.1. Data Model for ODS Data Model for ODS will include modeling data defined in this document. Data Dictionary and Metadata will be part of data model design process. 1. Fig. 2. Symbolic Representation of Data Integration in ODS

Clarify

Customer

ADC

PG/Clarity

Service

Bill

SAP

Collection

ODS

Project Plan – ODS Phase 1

Page 11 of 49

The following functions and entities will form part of ODS. − − − − − − − − − − − −

Services Product/Pricing Plan Customer F&F CUG Customer Acquisition/Order Order Management/Fulfillment MACD/Provisioning/Non Provisioning Billing Payment Collection Adjustments

− − − − − −

Trouble Tickets Fraud Rating CDR Count Channel Sales Org Inventory Management

− − Promotions − Discounts − Schemes 7.2. Synchronization ODS needs to be in Sync with the owner source systems and also will need to be check for de-synchronization amongst the various systems. The synchronization strategy will consist of following: 1. Tracking the TIBCO message success for the data received by ODS but not other target systems. 2. Running synchronization scripts periodically to report synchronization of ODS with systems. Once reported, regain lost synchronization in ODS. 3. Running Synchronization scripts in case of Outages as a part of recovery process. Project Plan – ODS Phase 1

Page 12 of 49

7.3. Initial Load Initial Load refers to loading data in the ODS for existing customers and their services from source systems. Initial load in ODS focuses on synchronization of data as missing or unmatched data from the owner sources can not be loaded due to referential integrity constraint in the ODS Data Model. Only data that is synchronized across systems will be initially loaded into ODS. Data that is rejected will be stored in error log. It will be loaded into ODS once synchronization has been achieved in the source systems. ODS will be put in production ready stage before first load occurs as once data is loaded in to ODS, changes occurring due to MACD will need to be captured by the ODS. During the initial loading, ODS will not raise error messages for MACD’s on TIBCO bus even if ODS does not have corresponding customer. Initial load in ODS will be in following sequence: 1. All Master Data Tables Master data tables for RIC will be loaded first in the ODS. These tables are independent of all other tables in ODS Data Model. Once loaded, they will create a constraint by the way of Foreign Key in other tables. These tables will not allow loading of data in linked tables that does not match with the data contained in Master Tables. This will ensure that referential integrity is maintained through out the ODS Data Model. Example: If a customer record comes to the ODS that has Pin code value not available in PINCODE master, the record will be rejected, sent to error log table, corrected and re-pushed to the CUSTOMER table. 2. Picking Customer Data from Clarify for CUSTOMER Table and verifying with other systems for synchronization Customer Data from ClariFy will be picked and checked record by record for any missing or unmatched data in the following systems: For Post Paid Customers − PG – MDN-MIN-RSN-CAF combination, Service Status − ADC – Pin code, Services Status − Clarity – Service Status Project Plan – ODS Phase 1

Page 13 of 49

− Clarify – Customer Contract For Pre paid Customers − − − −

PG – MDN-RSN-CAF combination, Service Status Comverse – Customer Details Clarity – Service Status Clarify – Customer Contract

If data is not synchronized across these systems, customer record will not be created in ODS customer table. It will be moved to error log for synchronization action for source systems. If the data is synchronized across systems, customer data will be inserted in CUSTOMER table constrained by the master tables. All data for that customer from other sources will also be loaded in ODS at the same time. This will ensure that synchronized data pertaining to that customer only is loaded in the system. The initial load will be done using Initial Load ETL and Initial Load TIBCO process that will do the following: 1. ETL Load process will load the Master Data 2. Hold all the MACD messages while the initial load is completed so as not to loose the changing status of information. The cleansing of data might take longer than anticipated, as the extent of desynchronization is not known. All system owners will be involved in the data cleansing effort on a record-by-record basis. It is expected that the cleansing will take four weeks time based on resolution from system owners.

7.4. ODS Development and Implementation

ODS is the data store that will have data defined in this document from EDM/Source Systems required for synchronized single view and tactical reporting. ODS will have integrated data from different owner systems to get single view at one place. Project Plan – ODS Phase 1

Page 14 of 49

ODS data model will capture details only to the extent it is required for query and reporting purposes.

Fig. 2. Symbolic Representation of Data Integration in ODS

Clarify

ADC

PG/Clarity

Customer

Service

SAP

Bill

Collection

ODS

8. Test Strategy

Testing

Planning

Unit / Module Testing

System /

Functional and

Integration

Data Integrity

Testing •

Testing •

Functional/Business

Performance

•

•

Testing / Staging

•

Documentation

(Internal) and

Process Test Cases

Benchmarks and

Infrastructure

•

Unit Test Cases &

Module Integration

& Results

test cases and

Results

Test Cases and

•

Test Cycle Plan

•

Integration Test •

•

UAT Plan

•

Governance and

Link Test Plan and

•

Security Test Plan

• •

and Results •

Test Cases

Regression Testing

Test Database Data Quality Tests

Results

Approval Process •

•

Results

•

•

•

End User

System Monitor /Alert Checks

•

Navigation/Usability

Environment

Administrator /

•

Operational Tests

Test Case Documentation Including Results

Page 15 of 49

Fig. 3. Test Plan for ODS

Fully Functional Testing and Staging

Regression Testing

Project Plan – ODS Phase 1

Install Guides System Monitors

•

Test Results •

Configuration Scripts

•

Feedback

and Results

•

Environment Setup Experience (Usage)

Document •

Replicated Staging

Backup and Recovery test cases

Batch Process

Testing •

results

Traceability

Testing

Configuration

Testing •

Test Strategy

RIC systems

Transfer &

Fail over

•

Application Code

End User

Performance &

9.

Project Plan – ODS Phase 1

Page 16 of 49

10. Information in ODS ODS will have the following information for customers: − − − − − − − − − − − − − − − − −

Services Product/Tariff Plan/Rate Plan Channel/OTC Inventory (Handset Provisioned & Non Provisioned) Schemes Discount Promotion Customer Details (CAF, Handset Details) Payment (Initial, Later & Deposits) Bill Information Collection Customer Account Balance Unbilled Usage Inventory (Including Stock In-Transit) Master Database Fraud CRM (TT)

11. Source Systems for ODS SAP − Inventory Data − Channel Data − Collection Data Clarity − Service activation Status Data Clarify − Customer Acquisition Form (CAF) Data − MACD Data

Project Plan – ODS Phase 1

Page 18 of 49

− Payment Data Portals − Payment Data − MACD Data PhoneGen − MACD Status − Service activation Status Data ADC − − − −

Bill Data (Without CDR’s) Bill Status (Open/Closed) Data Customer Account Balance Data Unbilled Usage Data

Master Data − − − − − − − − − − − − − − − − − − − − − − − −

SDCA MASTER LDCA MASTER CIRCLE MASTER BUSINESS CLUSTER MASTER PINCODE MASTER TOWN MASTER WAREHOUSE MASTER MATERIAL MASTER ZONE MASTER AREA MASTER PHONE MASTER MIN MASTER VANITY MASTER HANDSET MASTER AAA SDCA MASTER PRODUCT MASTER PROVISION MASTER ADJACENT SDCA MASTER BANK MASTER COLLECTION CENTRE MASTER COUNTRY CODE MASTER STATE MASTER STD MASTER VMS SDCA MASTER

Project Plan – ODS Phase 1

Page 19 of 49

− − − − − −

FRANCHISE PIN TOWN STATE MAS SAP STATE MAS COLLECTION CENTER OVER THE COUNTER (OTC) MASTER MAS SDCA MASTER CHANNEL PARTNER MASTER

12.

Project Plan – ODS Phase 1

Page 20 of 49

Project Plan – ODS Phase 1

Page 21 of 49

Project Plan – ODS Phase 1

Page 22 of 49

Project Plan – ODS Phase 1

Page 23 of 49

Project Plan – ODS Phase 1

Page 24 of 49

Project Plan – ODS Phase 1

Page 25 of 49

Project Plan – ODS Phase 1

Page 26 of 49

13.

Project Plan – ODS Phase 1

Page 27 of 49

14. ODS Project Plan

Project Plan – ODS Phase 1

Page 28 of 49

Project Plan – ODS Phase 1

Page 29 of 49

Sr.No. 1 1.1 1.3 1.4 1.5

Description Functional (Wireless) Functional Requirement Analysis Reports & Dashboard Synchronization Reports Analyze Business Rules, Triggers & Actions

Project Plan – ODS Phase 1

Start 4-Oct-04 4-Oct-04 25-Oct-04 29-Dec-04 3-Jan-05

End 16-Jan-05 14-Oct-04 7-Nov-04 5-Dec-04 16-Jan-05

Page 30 of 49

1.6 2 2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.3 2.4 2.5 2.6 3 3.1 3.3 3.4 3.5 3.6 4 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.4 4.5 4.6 5 5.1 5.2 6 6.1 7

Analyze Re-Inserts (De-Duplication, Householding, etc.) Integration (Wireless) Logical Data Model Synchronization Design Synchronization Check Program Design Subscribe regain Design Standardize Backend Processes (Run & Notification) Standardize Data Exchange Processes (email, Excel) Data Integration Design Initial Load Design Design Business Rules, Triggers & Actions Design Re-Inserts (De-Duplication, Householding, etc.) Functional (Wireline) Functional Requirement Analysis Reports & Dashboard Synchronization Reports Analyze Business Rules, Triggers & Actions Analyze Re-Inserts (De-Duplication, Householding, etc.) Integration (Wireline) Logical Data Model (Wireless DM Extension) Synchronization Design Synchronization Check Program Design Subscribe regain Design Standardize Backend Processes (Run & Notification) Standardize Data Exchange Processes (email, Excel) Data Integration Design Initial Load Design Design Business Rules, Triggers & Actions Design Re-Inserts (De-Duplication, Householding, etc.) Design & Development using HP Nonstop Suite of Products (Actual Dates to be provided by HP) EAI, ETL & Reports Design (Tool Specific) EAI, ETL & Reports Development Testing (Actual Dates to be provided by HP) Unit, Integration & Load Testing Deployment (Actual Dates to be provided by HP)

Project Plan – ODS Phase 1

3-Jan-05

16-Jan-05

4-Oct-04 4-Oct-04 15-Nov-04 15-Nov-04 15-Nov-04 15-Nov-04

16-Jan-05 14-Oct-04 28-Nov-04 28-Nov-04 28-Nov-04 28-Nov-04

15-Nov-04

28-Nov-04

29-Nov-04 22-Nov-04 3-Jan-05 3-Jan-05

5-Dec-04 28-Nov-04 16-Jan-05 16-Jan-05

6-Dec-04 6-Dec-04 13-Dec-04 27-Dec-04 3-Jan-05 3-Jan-05

2-Jan-05 19-Dec-04 19-Dec-04 2-Jan-05 16-Jan-05 16-Jan-05

6-Dec-04 6-Dec-04 20-Dec-04 20-Dec-04 20-Dec-04 20-Dec-04

2-Jan-05 19-Dec-04 26-Dec-04 26-Dec-04 26-Dec-04 26-Dec-04

20-Dec-04

26-Dec-04

27-Dec-04 20-Dec-04 3-Jan-05 3-Jan-05

2-Jan-05 26-Dec-04 16-Jan-05 16-Jan-05

2-Jan-05

30-Apr-05

2-Jan-05

30-Apr-05

Page 31 of 49

7.1 7.2 7.3

Operations Manual Administration Manual Production Ready

15. Resource Requirements

Project Plan – ODS Phase 1

Page 32 of 49

Functional & Integration Design -

Business Analyst/Project Manager Data Modeler Data/System Analyst

Deployment This is a tentative resource profile list from HP that will be finalized once the proposal is accepted. -

Project Manager (HP and Abc Inc) Solution Architect (HP and Abc Inc) System Analysts (HP and Abc Inc) Technical Focal Points (Abc Inc specially for HLR, Customer Care, IN, Provisioning, and Billing systems) Logical Database Designer (HP) Physical Database Designer (HP) Data Loader designer and developer (HP) ETL script developer (HP) RTID Developer (HP) Common infrastructure developer (Events, Error Messages etc.) (HP) Subscription Service Developer (HP) Test Library Developers (Test Plan for Unit, Integration, System, and Acceptance; Test Framework, Test Case Design, Test code and script development) (HP) Software Configuration Management Technician (HP) System Integrator (HP and Abc Inc) Database Administrator (Abc Inc) Network Administrator (Abc Inc) Systems Manager (Abc Inc) Production Planner (HP, Abc Inc)

16. Software & Hardware Requirements HP Non Stop suite of products will be deployed as a complete hardware and software solution. HP has proposed following: -

NonStop hardware S8x and standard systems software (G06.23 or later) NonStop WLS 8.1 SP2 HP NonStop Server Toolkit for Web Logic Server NonStop DTE (optional, only if data transformation requirements are identified) NonStop Server for Java 3.1 or later NonStop SQL/MX 2.0 or later JDBC/MX Driver 2.1 or later NonStop ODBC/MX server 2.0 or later NonStop RTID jar files and scripts Trillium for de-duping and cleansing of customer data prior to loading into the NonStop ZLEDS (optional, only if cleansing is an identified requirement)

Project Plan – ODS Phase 1

Page 33 of 49

-

Interface to ETL Tools (since Abc Inc is already using Ascential Datastage, we recommend use of Genus HSDCI) NonStop Data Loader to do the initial load of state and event info into the NonStop ZLEDS Fair Isaac Blaze Rules Engine Subscription Services Customized JMS Adapters to TIBCO In order to do Unit and Stress testing of the initial system as it is built, It will be necessary to build test drivers and interface simulators.

17. Risk Mitigation (Project Management Specific) TABLE 1: Risk Factors and Mitigation Risk Project Cancellation due to unexpected budget or resource withdrawals Project Delays due to inaccurate estimations, scope, infrastructure or standards changes. Skill Set Gap(s) – due to changes in development language(s), platform, infrastructure support, standards, staff or function-driven technology requirements. Missed Deadlines – due to Project Delays and affecting

Project Plan – ODS Phase 1

Business or Technical

Impact (H, M, L)

Probability

Business

High

Low

Business

High

Medium

Technical

High

Medium

Technical

Medium

Medium

Page 34 of 49

interdependent tasks and/or resource schedules Excessive Costs – due to unanticipated changes in chargebacks, vendor charges for hardware and/or software, resource requirements, scope or specifications Low Deliverable(s) Quality – due to functionality below specification, turnaround or quality of data, navigation and the like. Use of New or Immature Technology – due to unanticipated requirements of the functionality, development or interaction with an interdependent application. Fails to meet Business Needs – due to changed requirements, inadequate specifications, or ineffective testing. Disruption of Processing or Data Loss – due to changed requirements, inadequate specifications, or ineffective testing. Business Changes – due to new or altered regulatory requirements, internal or external client needs, or changes to the core business, functions, or methods of Abc Inc.

Business

Medium

Medium

Technical

High

Low

Technical

High

Low

Business and High Technical

Low

Technical

High

Low

Business

Medium

Medium

18. Constraints (Project Management Specific) Table 2. Constraints Constraints

Priority

Project Funding Staffing Priorities Business Involvement Support Team Involvement

High High Medium High High

Project Plan – ODS Phase 1

Page 35 of 49

Project Plan – ODS Phase 1

Page 36 of 49

Project Plan – ODS Phase 1

Page 37 of 49

Project Plan – ODS Phase 1

Page 38 of 49

Project Plan – ODS Phase 1

Page 39 of 49

Project Plan – ODS Phase 1

Page 40 of 49

Project Plan – ODS Phase 1

Page 41 of 49

Project Plan – ODS Phase 1

Page 42 of 49

Project Plan – ODS Phase 1

Page 43 of 49

Project Plan – ODS Phase 1

Page 44 of 49

Project Plan – ODS Phase 1

Page 45 of 49

Project Plan – ODS Phase 1

Page 46 of 49

Project Plan – ODS Phase 1

Page 47 of 49

Project Plan – ODS Phase 1

Page 48 of 49

Project Plan – ODS Phase 1

Page 49 of 49