ETA - ITMAS PROJECT PROJECT QUALITY PLAN

ETA - ITMAS PROJECT

PROJECT QUALITY PLAN

November 19, 2007 This publication was produced for review by the United States Agency for International Development. It was prepared by BearingPoint Inc.

PROJECT QUALITY PLAN Document Reference: ITMAS-PQP-QPlan-01-0711-E

ITMAS Internal & Confidential Egyptian Tax Authority (ETA) Date: 15/11/2007 Technical Assistance for Policy Reform II Page 2 of 100

ETA - ITMAS PROJECT

PROJECT QUALITY PLAN

TECHNICAL ASSISTANCE FOR POLICY REFORM II CONTRACT NUMBER: 263-C-00-05-00063-00 BEARINGPOINT, INC. USAID/EGYPT POLICY AND PRIVATE SECTOR OFFICE NOVEMBER 19, 2007 AUTHOR: FATOS QENDRO AND ITMAS PROJECT TEAM SO 16 DISCLAIMER: THE AUTHOR’S VIEWS EXPRESSED IN THIS PUBLICATION DO NOT NECESSARILY REFLECT THE VIEWS OF THE UNITED STATES AGENCY FOR INTERNATIONAL DEVELOPMENT OR THE UNITED STATES



Table of Contents

1 INTRODUCTION ......................................................................................................6 1.1 Purpose Of The Project Quality Plan......................................................................................................7 1.2 Field Of Application...................................................................................................................................8 1.3 PQP Validation and Evolution procedure ..............................................................................................9 2 APPLICABLE DOCUMENTS AND STANDARDS................................................. 10 2.1 Applicable Documents .............................................................................................................................10 2.2 Applicable Standards...............................................................................................................................10

2.2.1 PMI reference ........................................................................................................................................10 2.2.2 MOSIC™ Methodology;........................................................................................................................10

2.3 Quality Organization ...............................................................................................................................11 3 TERMINOLOGY..................................................................................................... 13 3.1 Abbreviations and Acronyms..................................................................................................................13 3.2 Definitions .................................................................................................................................................13 4 PROJECT PRESENTATION.................................................................................. 17 4.1 Project Objectives and Goals ..................................................................................................................17 4.2 Project scope.............................................................................................................................................17 4.3 Project Organization................................................................................................................................21 4.4 Subcontractor Organization....................................................................................................................22

4.4.1 Working Principles ................................................................................................................................22 4.4.2 Participants list.......................................................................................................................................22 4.4.3 Roles and responsibilities ......................................................................................................................23

4.5 Contractor ’s Responsibilities .................................................................................................................32 4.5.1 The ETA project team...........................................................................................................................34 4.5.2 ETA project member missions ..............................................................................................................35

4.6 Quality Assurance Organization.............................................................................................................37

4.7 Project Management Structure...............................................................................................................38 4.7.1 Principles of Project Coordination.........................................................................................................38 4.7.2 Project Operational Committee..............................................................................................................39 4.7.3 Delivery Project Board ..........................................................................................................................40 4.7.4 Project Steering Committee ...................................................................................................................42 4.7.5 Project Technical (functional) Committee .............................................................................................43 4.7.6 Escalation Procedure..............................................................................................................................44

5 PROJECT MILESTONES AND DELIVERIES ....................................................... 46 5.1 Project Phases ...........................................................................................................................................46 5.2 Delivery Segmentation...............................................................................................................................47 5.3 Deliverables And Project Documentation..................................................................................................48 5.4 Quality Procedure and Quality criteria.......................................................................................................51 6 QUALITY CONTROL MANAGEMENT .................................................................. 52 6.1 Principles...................................................................................................................................................52

6.2 Project monitoring and reporting...........................................................................................................53 6.2.1 Project reports........................................................................................................................................53 6.2.2 Quality indicators...................................................................................................................................54

6.3 Project reviews .........................................................................................................................................55 6.3.1 Subcontractor Quality reviews..............................................................................................................55 6.3.2 Joint Program/Project Review ...............................................................................................................56 6.3.3 Technical Implementation Review ........................................................................................................57 6.3.4 Review of Acceptance Activity and Procedure ....................................................................................57 6.3.5 Audit ......................................................................................................................................................58

6.4 Project risk management........................................................................................................................60 6.4.1 Risk Management ..................................................................................................................................60



6.4.2 Risk Management Structure...................................................................................................................61 6.4.3 Risk Activities Assessment....................................................................................................................61

6.5 Project Quality Control Plan ..................................................................................................................63

7 QUALITY ASSURANCE MANAGEMENT ............................................................. 65

7.1 Delivery management ..............................................................................................................................65 7.1.1 Software delivery management..............................................................................................................65 7.1.2 System environments.............................................................................................................................66 7.1.3 Documentation management .................................................................................................................68 7.1.4 Configuration management....................................................................................................................71

7.2 Validation and acceptance management ................................................................................................72

7.3 Incident (issues ) management ...............................................................................................................74 7.3.1 Incident assignment principles..............................................................................................................74 7.3.2 Escalation process..................................................................................................................................75 7.3.3 Resources and resolution process ..........................................................................................................76

7.4 Change management................................................................................................................................78

8 IMPLEMENTATION PLAN..................................................................................... 80

8.1 e-ris Solution Definition methodology ...................................................................................................80 8.1.1 Business Area Definition and High Level Functional specification ......................................................80 8.1.2 Detailed Specification and Technical Implementation ........................................................................81 8.1.3 the scoping and Specification Phase Outputs ....................................... Error! Bookmark not defined.

8.2 Bull Tax Application Solution Pilot Development and Implementation ...........................................82 8.2.1 Building the Application System Software............................................................................................82 8.2.2 Activities assigned to ETA Project development team........................................................................83

8.3 Roll out Phase ...........................................................................................................................................84 8.4 Implementation tools ...............................................................................................................................85

9 APPENDIX ............................................................................................................. 86

9.1 APPENDIX A: Project Committees members lists ............................................................................86 9.1.1 Steering Committee permanent members ..............................................................................................86 9.1.2 Delivery Project Board committee members ........................................................................................87 9.1.3 Project Operation Committee members.................................................................................................88 9.1.4 Committees report distribution lists.......................................................................................................90

9.2 APPENDIX B: FORMS TEMPLATES .............................................................................................92 9.2.1 Project follow up report .........................................................................................................................92 9.2.2 Milestones follow up report ...................................................................................................................94 9.2.3 Acceptance form....................................................................................................................................95 9.2.4 Change request note template ...............................................................................................................98 9.2.5 Risk Record form...................................................................................................................................98 9.2.6 Initial Risk Portfolio .............................................................................. Error! Bookmark not defined.

9.3 Appendix C: Lots definition, Detailed WBS, RISK PORTOFOLIO, AND WORKPLAN ...................





Introduction

Bearing Point has been engaged by the U.S. Agency for International Development (USAID) to implement the Technical Assistance for Policy Reform II (TAPR II) project.

TAPR-II directly supports Strategic Objective-16 (SO 16), which is entitled "Environment for Trade and Investment Strengthened.” The project is divided into seven components, and the third, component C – Macroeconomic Stability, is designed to modernize the tax regime and the administrative agency. Private sector development is facilitated by a tax system that is easy to comply with, has moderate tax rates, and is administered fairly and efficiently with certainty regarding tax liabilities. In the absence of such a system, private enterprises will be crippled in their efforts to expand, economic activity will be driven underground; and foreign investment inflows will be severely constrained. Concurrent with the policy reform the component’s activities will also support a comprehensive modernization of the tax administration with a view to meeting the need for consistent application of the tax laws. In this context, an important role in the realization of the above- mentioned objectives will play the new Integrated Tax Management Administration System (ITMAS).

The new system will play a key role in the modernization of the merged organization by improving the efficiency and effectiveness of Tax operations.

The new system has been selected through an international competition. Bearing Point and ETA have selected the consortium lead by Raya as the best proposal at the time of the bid process.

The Bearing Point’s TAPR-II project team and the Egyptian Tax Authority (ETA) will be jointly overseeing this project. Bearing Point is the legal contractor and ETA the Client or project owner. For the purpose of this document, both Bearing Point and ETA will be defined as ‘Contractor’. Raya USA, Ltd and Bull SAS will be defined as ‘Subcontractor’. As the supplier of the ITMAS project application Solution, Bull SAS will propose its own project management methodology and the corresponding plans, in coordination with Raya USA, Ltd. In the present document as on all the project management plans, the reference to the ITMAS project will be used in a limited sense, as defined by the scope of work of the Subcontractor, and covers the Bull e-ris Tax application software delivery, configuration, customization, integration, training , roll out services for 10 tax tax offices. . Other activities included to the ITMAS project but neither under the responsibility of the Subcontractor or directly in relation with it, are not covered by these plans. Such activities includes, but are not limited to, the performance of a BPR (Business Process Reengineering) program, and a Change Management program. The Project management plans include the following documents:

• Master Project Plan (Project Charter) • Project Quality Plan, including Annexes (Work Plan, Delivery Schedule, Initial

Risk Analysis); • Test & Acceptance Plan; • Change Control Plan; • Configuration Management Plan; • Training Plan; • Documentation Plan;



• Warranty and Support Plan;

The Project Quality Plan (PQP) is the main reference document for the Quality System defined by the Subcontractor for its deliveries under the Contract. Its objective is to describe the practices, means and the sequence of activities and the monitoring of quality during the execution of the Project. These activities are created in order to guarantee that the objectives will be reached and the Project will be successful.

The PQP clarifies the scope of the Project, identifies the deliverables, outlines the schedule, and defines the organization and set of roles and responsibilities for all parties involved in the project, the procedures used for co-ordination and the methods used for managing and controlling the project.

The PQP is the first deliverable of the Project and it is define

• the methodology and standards applied for the project management; • the organization and the project management coordination; • the project structure, phases and delivery process; • the quality assurance procedures and the quality control methods; • the risk analysis process.

Purpose Of The Project Quality Plan

The overall purpose of the PQP document is to define the means by which the Contractor will be able to manage the relationship with the Subcontractor to ensure that the system is designed, customized and delivered in order to meet with the Contract exhibit B and the specifications agreed during the scoping and design phases of the Project.

The Project Quality Plan is the first Deliverable in time of the ITMAS Project and provides the framework within which the system will be delivered and implemented.

The PQP aims at defining the rules which will govern the quality assurance along the project, including:

The project organization:

• Project organisation structure, • Roles, responsibilities and obligations.

The project management: • Project management methods and tools, • Project reporting, • Meetings and correspondence, • Schedule management, • Acceptance, • Client satisfaction • Risk management, • Change management.

The project delivery: • Delivery approach, • Delivery environment,

The management of delivery and quality:



• Quality objectives & evaluation, • Project reviews & audits, • Deliverable reviews, • Supplier reviews & audits, • Quality audits

The success of the Project will depend on the commitment to quality by all the parties and the application of the defined procedures and standards.

The purpose of the ITMAS Project Quality Plan and the Project Management Plans are the following:

• To define the content, format and sign-off and review process and responsibilities for each deliverable;

• To define roles and responsibilities, for both the Contractor and the Subcontractor, with emphasis on the required skill necessary to address the complexity and risks of the Project;

• To show how changes and issues can be identified and reported;

• To make visible the means that are and will be applied to meet the Contractor requirements, both technical and quality;

• To provide the quality authorities (from both Parties) with information that allows them to organize quality assurance and quality control activities that include transfer of information, verification actions, etc.;

• To list all the participants of the project, procedures, rules and applicable methods;

Field Of Application

The Project Management Plan documents apply to the activities to be performed by the Subcontractor in order to deliver its Scope of work for the ITMAS project, including:

• the delivery of the Master Project Plan, the PQP, the related Project plans and the subsequent reissues;

• the production of progress reports (project and quality management); • the delivery of the Bull Tax Application (e-ris); • the analysis, design, build, test, documentation and delivery of additional functionality and

customization in order to implement an application Solution for ITMAS; • the installation of the system in the ETA environment; • the training of users. • the Pilot commissioning (LTC and MTC) and the roll out supervision on 5 MTC and 5

STC sites. Other activities of the ITMAS Project but excluded from the Contract; that remain the responsibility of the Contractor include:

• mobilization of the ETA personnel involved in the project and managing them; • provision of test data for elaboration of test cases • provision of Acceptance Test Cases • performance of Acceptance Tests; • provision of data for loading into the ITMAS system; • definition, access supply and support of external systems to be interfaced to the Bull Tax

Application; • provision of hardware and the operational support for the application and database server

and communication network;



• parallel run and cut-over to the new system.

PQP Validation and Evolution procedure

The PQP is defined during the project initiation phase and will be approved by the Contractor before being in force.

A first and complete version will be submitted by the Subcontractor Quality Manager for comments. He will collect all the comments and improvement requests.

All the remarks will then be analyzed by the Subcontractor Quality Manager and Project Manager in order to integrate them, when applicable, into the document.

Any change should be agreed between the contractor and the subcontractor taking into account the existing practices in both sides, the common objectives to follow a total quality process without impacting efficiency and productivity of the working team.

An updated version of the PQP will then be prepared, for a final review before acceptance by the Contractor project manager.

Once approved the PQP should remain in force for all the project stakeholders. The PQP will remain as a living document after acceptance and may continue being modified under the formal procedures of Changes as defined hereafter.

The CONTRACTOR's Project Manager will be responsible for maintaining the Quality Plan when revisions arise. However, any changes to this Quality plan should be approved by the Project Operation Committee. The changes to Quality Plan will be circulated to all those on the distribution list.

The PQP document and its evolution will remain the ownership of Bull until final acceptance of the Project deliveries, and then the ownership will be transferred to ETA.

Some changes can also affect the annexes (member lists), the forms template and should be directly integrated and approved without a lengthy validation.

All the changes will be logged into the PQP cover page with a justification.

In case the change request that substantially impact the current version and modify the project management agreed procedures, any party can escalate to the Project Board Committee or to the Steering Committee for arbitration and decision.



Applicable Documents and Standards

Applicable Documents

The applicable documents are: • The Contract AID-2007-C-00063-01301 signed between Bearing Point and Raya including

the following exhibits that are related to the project scope: Exhibit B: the Request for Proposal and amendments

Exhibit C: Project scope of Work

Exhibit G: Revisited technical offer BAFO dated April 3rd and April 22nd

Exhibit H original technical proposal dated December 29, 2006

Applicable Standards PMI reference PMI - Project Management Institute : project disciplines and practices (www.pmi.org)

Published documentation, among which the

PMBOK®: Guide to the Project Management Body of Knowledge (PMBOK® Guide). 2004

MOSIC™ Methodology; Bull will use milestones from the MOSIC™ methodology for tracking project advancement, contractual management and financial management of the project. This methodology is for Bull internal use only. The milestones (Business Commitment Reviews) occur at clearly defined stages in the project and are a mandatory Bull internal requirement for Bull Systems Integration projects.

For the Contractor, the use of MOSIC™ will be visible through the formal review and inspections required at all levels and stages that will be conducted by Bull and will provide reporting information for all the project stakeholders.

There are three types of reviews, namely those dealing with business issues, management issues and technical issues as shown in the next figure.

Business Commitment Reviews (BCR)

Program StatusReviews

Project WorkProducts Review

IndependantProject Review

(IPR)

Joint ProgrammeReview

Design Review

Business Reviews

ManagementReviews

TechnicalReviews

Fig : MOSIC Reviews The Quality Management of this project will be in accordance to the SUBCONTRACTOR MOSIC™ standards.

http://www.pmi.org/



Inputs Tools & Techniques Outputs

Quality Planning

Contract

MOSIC™ Standards

Project Charter

SUBCONTRACTOR 's Proposal

Standards included in the Project Quality Plan

Risk Management Tools

Business Process Flows

Prescribed MOSIC™ documentation

The Quality Plan

BCR Checklists

Master Project Plan

Quality Assurance

Project Quality Plan

BCR Checklists

Project Plan

MOSIC™ documentation

ITMAS adopted tools

Business Control Reviews Recommendations

SUBCONTRACTOR ß Testing

Quality Control

Acceptance Testing checklists

Project Quality Plan

MOSIC™ Checklists

MOSIC™

Acceptance Testing

ITMAS adopted tools

Change Requests

BCR Recommendations

Acceptance Testing Results

Quality Organization

Both parties (Contractor and Subcontractor) are committed to total quality management.

As entity in charge of the project management for the delivery of the project supplies, Bull SAS will propose a set of quality assurance and quality control procedures which need to get approval by the Contractor

The quality system will combine the inputs from Bull SAS (MOSIC™ Guidelines) and from the ETA.

Fig : Positioning Project quality organization for ITMAS

I TMAS QUALITYORGANIZATION

TQM ETA Committee

ITMAS PROJECT SPECIFIC PLANNING

BULL SMQSystem Quality

ManagementISO 9001- 2000 Certified

Quality Reporting

I TMAS QUALITYORGANIZATION

TQM ETA Committee

ITMAS PROJECT SPECIFIC PLANNING


Management


ManagementISO 9001- 2000 CertifiedISO 9001- 2000 Certified

Quality Reporting



Most of the Bull Quality Assurance procedures where presented into the Subcontractor’s proposal (Contract exhibit H).

During the Project initiation phase, Bull Quality Manager will integrate into the PQP some extensions proposed by the Contractor whenever they are not in contraction with the Bull Quality Management System.

The main objectives of these adaptations are to facilitate the integration of the Contractor personnel into the Project quality system for ITMAS and to permit an easier reporting to each quality management entities.

Bull Project Manager will be in charge of the application of all the quality assurance procedures and will present the quality indicators at all the Delivery Project Boards and when needed (intensive acceptance phases ) during the project operation committees.

Bull Quality Manager reports to Bull Quality Corporate organization; he will apply quality controls (reviews) and will present the Project quality performance status to the Bull Quality organization.

In a symmetrical manner, the ETA Project Manager and Bearing Point Contract manager (the Project Technical Adviser) can use the project quality reports to prepare their own reporting towards ETA TQM committee or Bearing Point- USAID project quality reviews.

.



Terminology This Section lists the general terms (abbreviations and acronyms), as well as the list of terms that may lead to incomprehension, misunderstandings or ambiguities.

ABBREVIATIONS AND ACRONYMS

Abbreviation Meaning API Application Programming Interface

BCR Business Commitment Review

BP Bearing Point

CM Contract Manager - Raya CM - Bearing Point CM

CR Change Request

DFS Detailed Functional Specification

DBA Database Administrator

ETA Egyptian Tax Authority

BULL e-ris BULL Software Suite for Revenue Tax Authority Information System

HW Hardware

ISO International Standards Organization

ITMAS Integrated Tax Management Administration System for the Egyptian Tax Authority

LTC Large Taxpayer Center (ETA office in charge of large taxpayers)

MOSIC TM Management of Systems Integration Contracts

MTC Medium Taxpayer Center (ETA office in charge of medium size taxpayers)

PM Project Manager ETA PM - BULL PM ..

PQP Project Quality Plan: (Basis of the maXXIme methodology)

QA Quality Assurance

QM Quality Manager

SBA Senior Business Analyst

STC Small Taxpayer Center ( ETA office in charge of small size taxpayers)

SW Software

TPM Technical Project Manager

TQM Total Quality Management committee in charge of quality assurance and control of the ETA Information System

UML Unified Modeling Language

DEFINITIONS

Term Definition Acceptance ; Acceptance of the Deliverable

A formal written statement made by the Contractor that a delivered product or a service (Deliverable) fulfils the related specified requirements. Acceptance report is used to record the Acceptance Statement (or rejection)

Acceptance Criteria Key statements supplied by the Contractor and agreed by the Subcontractor at any specification phase that define the acceptable level that must be achieved before the Beneficiary Institution (ETA) will sign off and accept the product or service (Deliverable).



Term Definition Acceptance Testing A formal testing of contractual Deliverables as defined in the Service Contract and PQP. The tests

are performed by the Beneficiary Institution (ETA) according to the Test Plan, to determine whether or not the system satisfies the agreed Acceptance Criteria.

Anomaly Any condition that deviates from expectations based on contractual specifications, including requirements specifications, design documents, user documents, standards.

Application System Software A set of Bull Tax Application (e-ris) software modules to be delivered and customized by Bull to meet the ITMAS project requirements

Audit An independent examination to determine whether activities are implemented effectively and the related results are suitable to achieve objectives.

Business Commitment Review A formal internal Bull procedure where Bull Project Manager justifies to Bull management that Bull can fulfill particular commitments.

Certificate of Acceptance A signed off document issued by the Contractor certifying acceptance of a Deliverable.

Change Control A process, by which a change is proposed, evaluated, approved or rejected, scheduled, and tracked.

Change Request A formal request from one party of the Contract to the other, to modify a requirement as defined in a agreed Controlled Document or to amend an already accepted Deliverable. This is subject to the Change Control Procedures. The changes may be of "functional" (application's functionality) and "non-functional" (project procedure, organization, delivery schedule, etc) nature

Client means ETA, the project owner or project beneficiary

Confidential Information means any proprietary information , noted as such, for which all the project participants should strictly follow the rules defined in the Documentation Plan or refer to the project management authority before any copy or usage

Configuration The functional and physical characteristics of hardware, firmware, software, or a combination thereof, as set forth in technical documentation and achieved for a Deliverable.

Configuration Management A process whereby all products (base and systems software,, etc) and Deliverables are clearly identified as to their version and release numbers so as to control the evolution of systems components during the development process.

Contract means the contract referenced AID-2007-C-00063-01301, dated 2007, September 11th, between Bearing Point and Raya in respect of the Project.

Contractor Legal contractor means Bearing Point , ‘ Contractor’ means for the purpose of the PQP, Bearing Point or the Client (ETA)

Contractor’s Contract Manager Bearing Point , assigned project manager in charge to advice the Client and to validate the Subcontractor’s deliveries from the view point of the Contract.

Controlled Document List The full set of contractually binding documents.

Customization Customization of the application means the modification of the existing parts of the standard application's functionality to fit the particular needs of a given customer

DBA Data base Administrator

Deliverable Each phase of a project results in some outputs. These outputs are clearly defined and described as deliverable, that must be checked and formally accepted as part of the management process before progressing to the next phase. Deliverables are grouped in Lots

Delivery A supply of the deliverables referred to in the contract. Is subject to formal procedures.

Delivery Control it is the person responsible for the preparation of the delivery

Domain Manager The Domain Manager is a representative of the Contractor or Project Owner to manage and review the Analysis and User Functional testing activities related to particular module or related group of modules (domain). The Domain Manager is also used for the Technical Expert responsible for the particular technical domain in the ETA organization (database Administrator, network administrator, etc.)

Environment The infrastructure within which a system is developed ("development environment"); in which it runs ("production environment") or in which it is maintained ("maintenance environment"). It includes the hardware, network, basic software, documentation, and procedures within which the system operates.

Final Acceptance Final acceptance of the project then all deliverables satisfies final acceptance criteria. Warranty period starts after final acceptance.

Iteration or Application Group A “mini-project”, containing all the necessary life-cycle phases of analysis, design, implementation, integration, and testing. Implements parts of the system functionality (subset of use-cases).

Lot The scope of the project is divided into Lots. Each Lot is a combination of products and services to



Term Definition be delivered together by the Subcontractor. The Lots all have delivery, installation and test and acceptance activities.

Minor Change Requests Issues related to the look and feel aspect of the system. Slight changes to the Functional Specification (for example, change of a business rule, demanding a little update in a use case and a change of e.g. an arithmetic operation, mark in one or two places in code).

Minutes of Meeting Documented and signed off decisions/actions from a meeting.

Incident An incident occurs, when the Bull Tax Application, or part of it, doesn’t operate as expected by a user The form used to report "incidents" are System Incident Reports (SIRs)

Localization Translation of user interface, reports and user documentation to local language (Arabic)

MOSIC™ Bull’s, internally used, ISO 9000 compliant methodology, providing a comprehensive set of rules, techniques, procedures processes and tools helping to ensure the management of complex systems integration contracts.

Phase A logical grouping of Lots where the end of each such grouping provides a clear management checkpoint as to project advancement. These are clearly identified in the project Schedule

Pilot The complete set of modules delivered and functionally operational on a limited number of sites or actors. Two pilots are foreseen on the ITMAS project: LTC Pilot and MTC Pilot.

Project File A file in which all documents related to the project management are filed or referred to. It includes all documentation produced by the project except the technical documentation.

Project Delivery Board A joint committee grouping project responsible members from the Contractor, the Client and the Subcontractor (Raya and Bull); in charge to control the project execution and to solve any issue between parties. Several project committees are defined: Project Operational Committee, Delivery Project Board, and Delivery Steering committee. Committees mission and composition are described into the PQP.

Prototype Within the Project, a prototype will mean a working but domain limited software Deliverable used to test one or many domains together before the readiness of the complete pilot

Project Operation Committee A joint committee grouping project responsible members for project day to day operation from the Contractor, the Client and the Subcontractor (Raya and Bull)

Provisional acceptance Provisional Acceptance occurs at the different dates for different Deliverables and the complete schedule is included in the workplan attached to the PQP

Requirement A functional or performance condition to be met in order to comply with the project scope and the Contract exhibit B.

Review A formal meeting at which documents/results are presented to the Contractor and the Beneficiary Institution (or internally), or other interested parties for comment and approval. Each development phase should end with an "end of phase review".

Review Team A team created by the Subcontractor or the Contractor

Risk Event or situation which, if not addressed, may adversely affect the project or the system under development.

Scope of Supply A clearly specified and complete set of Deliverables (software, application, services, training, etc.) and services to be provided by the Subcontractor under this Contract.

Solution Refers to the Bull e-ris application software, configured, customized and localized to fit with the Contract’s exhibit B requirements.

Specification A document stating requirements. Specifications emerge from user requirements and are refined into Detailed Functional Specifications.

Standard Software or Horizontal Software

A set of software being part of the target environment (development, integration and production), provided by the ETA and supported by the vendors; as examples: Microsoft Windows Server, Microsoft SQL Server, J2EE Application Server, Web Server

Delivery Steering Committee This ad hoc committee is the highest directing body in the Project consisting of both the Subcontractor ’s and the Contracting Party’s members, and chaired by the Contracting Party.

Systems Integration The development and delivery of a complete Solution according to the agreed requirements, including applications software, interfaces, data migration and other services (like user training).

Task A certain amount of work to be performed. It is specified with respect to: the necessary input deliverables, the resulting output deliverables, the roles (who is doing what), start and end dates,



Term Definition the amount of effective effort needed to perform it and the dependencies to other tasks.

Technical Documentation Technical documentation is the documentation describing the technical part of the Bull Tax Application Software documenting the Solution architecture (both logical and technical), the rules and parameters for installation, administration and operation.

Test Case Detailed instructions, specific conditions and its associated data used to prove the functional implementation of a requirement. Test Cases include Test Scenario (or scripts) and Test data.

Test Scenario A description of a business process which must be tested. This is elaborated with Test Cases.

Test Specifications Detailed specifications defining how each test will be conducted and also defines acceptance criteria, timeframe to fix each category of Anomalies, requirements for personnel involved and the responsibilities of each Party. It will be prepared for each test

Testing Process of exercising/evaluating a system (or part of a system) by manual or automated means, to verify that it satisfies specified requirements and to find residual errors (by identifying differences between expected and actual test results).

Training Manual An end-user help manual used by users during the application course. (can be a subset of the user manual)

User Manual An end-user handbook explaining how to use the ITMAS application. Final version of these manuals will be translated in Arabic.

Validation A process of evaluating software at the end of the software customization and integration process to ensure compliance with the pre-defined requirements.

Verification A process of evaluating the Deliverables of a given phase to ensure correctness and consistency with respect to the specifications and standards provided as input at the beginning of that phase.

Version Control In general: the control of different versions of a Deliverable. The Deliverable can be a system or a part of a system as well as a document.



Project Presentation The ITMAS Project is related to the implementation of an integrated Tax Solution for the ETA. This Solution complies with the key objectives of a contemporary Tax Information System, provides improved revenue collection, by enforcing compliance programs and by bringing non-compliant taxpayers into the system. Such new system, perceived by citizens as a system where everyone pays their fair share, will increase the likelihood of voluntary compliance.

Project Objectives and Goals Bearing Point and the ETA are undertaking the TAPRII program aimed at improving ETA 's effectiveness and efficiency. One of the primary focus of this initiative is the technical implementation and the development of a tax application with the goal of developing and improving the existing tax administration and collections process, as well as implementation of a fully integrated technology application to manage taxpayer information and automate manual processes.

The main objective of this Project in general as described in the Contract Exhibit B, is to deliver, adapt, and implement a proven and successful software application Solution in order to meet with the objectives of TAPRII Program.

The description of the Standard system architecture is provided in the Subcontractor's technical proposal (Contract exhibit H). This Solution is the core of the ITMAS System architecture and its description is the part of ITMAS Technical Documentation to be delivered during the course of the Project.

PROJECT SCOPE The objectives of the Integrated Tax Management Administration System (ITMAS) project consist:

(i) Development of requirements and system architecture for successful implementation of ITMAS including the interface definition with other external institutions and existing e-services.

(ii) Delivery of technical specifications for any modifications for the existing hardware, networking and communication infrastructure, system software and Relational Database Management System (RDBMS).

(iii) Implementation of the new system in the designated offices (LTC and pilot MTC).

(iv) Migration of taxpayer data as clarified in data migration strategic document to be delivered.

(v) Training of technical staff and end users.

(vi) Roll-out the system in 10 additional offices (5 MTCs and 5 STCs).

(vii) Maintenance and Technical Support services.

The ITMAS functionalities are divided into 3 groups according to the development and implementation strategies and their priorities in the administration of tax procedures.

The premier group includes the functionalities related to the basic operations in a tax administration. The second group includes the audit and enforcement procedures and the third group completes the rest of functions including the management information system,



which monitors and provides directions to the decisions to be taken for the improvement of performance in the management of tax administration.

The Subcontractor will provide the ETA with the Tax software application, in order to meet the contractual obligations as defined in the Contract. The application will include the Application System Software and related services. A Pilot of the application will be performed in 2 sites, the LTC and one MTC to validate the application and to prepare its roll out to ten other sites, 5 MTC and 5 STC.

The ITMAS Solution will be build from the Bull Tax Application ( ) software package as presented on the following schema.

All the ITMAS domains (12) can be covered by the Bull Tax Application modules.

Three main delivery batches have been proposed by the Contractor’s RFP in order to provide a phased and continuous implementation.

For the ETA project, the following modules must be delivered and customized, business domain by business domain. These business domain definition, or Business Areas, will be validated at the beginning of the project (Lot 002 – Business Area Definition).

External component already configured for standard reports

Assess-ment

Registration

Security

Standard Letters Taxpayer notes Files & document control

Returnsprocessing

PaymentOffice Mgt

Taxpayer Accounting

Rev

enue

Acc

ount

ing

Provisional payments

Enforcement Case Mgt

Audit

Objections & appeals

MIS

OC

R

Inte

rnet

por

tal

channels

External components

modules

XML

PKI

Imaging

Business Intelligence

Configuration

Ris

k A

sses

smen

t

Refunds

Compliance Bank

counter

Internet

XML

Audit Mgt

Exte

rnal

In

stitu

tions

External component already configured for standard reports

Assess-ment

Registration

Security

Standard Letters Taxpayer notes Files & document control

Returnsprocessing

PaymentOffice Mgt

Taxpayer Accounting

Rev

enue

Acc

ount

ing

Provisional payments

Enforcement Case Mgt

Audit

Objections & appeals

MIS

OC

R

Inte

rnet

por

tal

channels

External components

modules

XML

PKI

Imaging

Business Intelligence

Configuration

Ris

k A

sses

smen

t

Refunds

Compliance Bank

counter

Internet

XML

Audit Mgt

Exte

rnal

In

stitu

tions



ITMAS domain Module Abr Group

Control Area e-ris V3 System and User Administration ADM I-A

Registration Area e-ris V3 Registration REG I-A

Control Area e-ris V3 Taxpayer Notes TPN I-A

Assessment Area e-ris V3 Returns Processing RET I-B

Assessment Area e-ris V3 Taxpayer Accounting TAC I-B

Enforcement Area e-ris V3 Compliancy CMP II

Revenue Accounting Area

e-ris V3 Revenue Accounting RAC I-B

Revenue Accounting Area

e-ris V3 Payments Processing PPR I-B

Assessment Area e-ris V3 Provisional Payment PRO I-B

MIS area e-ris V3 Management Information (MIS) MIS III

Enforcement Area e-ris V3 Case Management DBT II

Objection and Appeal area

e-ris V3 Objections & Appeals OBJ III

File and document Area

e-ris V3 File & Document Control FDC III

Taxpayer Audit Area

e-ris V3 Audit & Inspections AUD II

Control Area e-ris V3 Standard Letters STD I-A

Assessment Area e-ris V3 Tax Rules Maintenance RETm I-B

Assessment Area e-ris V3 Tax Rules Engine RETe I-B

Taxpayer Audit Area

e-ris V3 Audit Rules Maintenance AUDm II

Taxpayer Audit Area

e-ris V3 Audit Rules Engine AUDe II

In addition to functional modules, the Solution requires several administration and rule maintenance modules.



Security management The Security sub-module (part of the System and User Administration module) allows the System Administrator, Office Administrators, and System Controllers to maintain users and related access rights to the system

A set of tools are needed to configure the Bull Tax Application modules and to decrease the customization effort:

• Tax Rule engine The engine will be configured for each tax..

All fields entered in the return declaration can be used by the Tax rule and compliancy engine.

After engine execution the returns can be validated or discarded.

• Audit Rule engine e-ris Audit Rules, along with e-ris Tax Rules allows for the setting of Audit profiles and scoring both at the National and Tax Office level.

The Audit Maintenance module is used to maintain the data that supports the audit regulation and trigger Rules to be added, modified, or deleted according to the changes in the business logic.

A set of Solution development and maintenance utilities are delivered to apply changes to the modules’ screen forms and to the workflows.

• FlexFlow Designer: a graphical tool to model workflows and the activities, branches, and specific nodes they contain. FlexFlow Designer also features a graphical user interface to maintain the business rules repository.

• FlexForms Designer: a graphical tool to draw the application screens. FlexForms Designer integrates with the FlexFlow Data Model Controller to allow for easy binding of screen objects (such as entry fields, tables, lists of values) to abstract entities.

• Reports generation: in addition to the standard reports delivered with all the e-ris modules, which should be customized if needed, Crystal Reports designer will be used by Parties (Contractor and Subcontractor) groups, for developing specific reports.



PROJECT ORGANIZATION The Project requires the involvement of three main skills:

(i) Functional (business oriented) experts able to design the software Solution in order to match the TAPRII program (BPR outputs and target working procedures for the ETA merged organization)

(ii) Technical (IT oriented) experts able to implement the Bull Tax Application software Solution into the ETA production environment and become familiar with the customization – configuration methods

(iii) Support and training people to sustain the pilot and the roll out centers and help ETA on the business transformation

Both parties must provide such skills with associated responsibilities in order to obtain a successful Solution implementation.

Ra

y a/ Bull

PM

O ET

AP

r oje

ctM

gt

Functional ConsultantsExperts

Developers

System IntegrationSA , Security , Interfaces ,

Tests

TrainersHelpdesk /Operation support

ETA Functional Integration team& Functional Consultants

ETA Project team Business Analysts, Developers,System and support engineers

ETA Functional Consultants& key users

Project organization

Ra

y a/ Bull

PM

O ET

AP

r oje

ctM

gt

Functional ConsultantsExperts

Developers

System IntegrationSA , Security , Interfaces ,

Tests

TrainersHelpdesk /Operation support

ETA Functional Integration team& Functional Consultants

ETA Project team Business Analysts, Developers,System and support engineers

ETA Functional Consultants& key users

Project organization



SUBCONTRACTOR ORGANIZATION The consortium in charge to deliver the tax application and the related services is composed by RAYA USA and BULL SAS.

RAYA USA is acting as ‘prime contractor’ and is the primary interface to Bearing Point.

Bull SAS is acting as a ‘subcontractor’ of Raya USA.

Working Principles

Bull SAS will deliver Bull Tax Application software package ( ) and the framework Bull FlexStudio as the main building blocks for the ITMAS Solution.

Raya USA will encompass with the contract management and with application support services such as the localization, system and functional testing, end user training and first level support and help desk during the roll out period.

As per the scope of work defined between Raya and Bull, all the activities are under Bull responsibility but contract management and end user training.

For this reason, Bull SAS will apply its methodology for designing and customizing the software and will be in charge of the project management activities.

An internal coordination between Bull and Raya will be put in place in order to prepare all the project management activities and to present a consistent position of the consortium on all the committees.

Participants list The following organization is the initial Subcontractor team, it can be changed or extended depending on the project needs.

The hereafter table indicates which individuals fulfill which roles as explained in the Proposal:

Project position Structure Mission

Contract Manager Raya Primary contractual interface between Raya and Bearing Point

Project Manager Bull Project management; coordination of all the subcontractor’s participants

Technical Manager Bull Solution integration within customer environment; Fault and change management, detailed reporting to Bull project manager

Quality Manager Bull Quality assurance and Quality control planning.

Solution architect Bull Functional analysis and design. logical architecture

Senior Business Analyst Bull Functional design and customization definition



Development Manager Bull Detailed implementation of customization and software delivery packaging

Experts Bull Physical architectural design, technical services design

Business Analysts Bull Software configuration, functional testing assistance, Documentation personalization.

Application Support Raya Administration and operational support

Software Integrator Bull Manage the software integration, and installation on the target environment. Data migration supervision.

System and DB administrator

Raya Development and integration environment management (save restore, configuration mgt, tuning); Installation of the standard software. System testing and tuning on the target production environment.

Training to project teams Bull Trainers in charge of Technical training for IT and of Functional training for ETA business consultants and advanced users

End User trainers Raya End User training

Senior Developers Bull Customization of e-ris modules according to the functional specifications.

Help Desk Raya Primary interface (level 1) to the ETA business centers during the pilot and roll out phases.

Roles and responsibilities The main operational roles are:

The Contract Manager (Raya) supervises the delivery of the Project Supply and the acceptance processes.

• He reports to Raya Project Management General Manager who is a permanent member of every Delivery Steering Committee and Project Boards.

• He has the financial responsibility of the Project for RAYA. • He is the main point of contact between the Contractor (Bearing Point- ETA) and

the Subcontractor and will be a permanent member at all the project management meetings.

• He has regular meetings with the Contractor’s contract manager to follow the contract execution (acceptance notices, invoices, change requests).

• He defines with the project managers the agenda of the all the coordination meetings as per the Subcontractor ‘s proposal for the items to be processed.

• He will act as the primary entry point for all the official claims, or alerts generated by the Contractor and will define with the Subcontractor’s project manager the best action plan to be presented to the POC or Delivery Project Board.

• He is the main point of contact between Raya and Bull and participate to all the consortium’s coordination meetings

• He manages directly all the actions assigned by the consortium’s coordination meeting to Raya such as (but not limited to) resources staffing and end user training.



For the operational project execution, a Project Management Office will be set up and headed by the Subcontractor’s Project Manager.

The PMO is an internal Subcontractor’ project management structure which will help on the daily reporting and communication exchange. The PMO has no official position but the mission assigned to each of its members.

The PMO includes the Subcontractor’s Project Manager (PM) and:

• A technical project manager (TPM) • A quality assurance manager (QA) • A project assistant for surveying all alerts, mails, document transmission between the

PMO and the various teams

The PMO team role is to concentrate all the documents and action plans related to the project control and monitoring.

• Detailed task schedule for all the project participants ( on site, off site, holidays, replacement for some activity)

• Project management reporting including all the presentation and reports for the POC, Delivery Project Boards and Steering Committees.

• Documentation management : version management, document distribution, document status (validated, on correction)

• Delivery notices • Acceptance notices for all the works, lots, phases • Quality control reports: quality indicators, project reviews reports and action plans • Risk Management activities documents: risks forms and risk assignment notes, • All the documents associated to Alert Management or escalation.

The Project manager relies on team leaders to structure all the task execution and control.

The following chart shows the Subcontractor’s project organization.



-

Senior Business Analyst

Solution Architect

Business Analyst

Business Analyst

.

Business Analyst

CompetenceCentre

Developers

IntegrationEngineer

DB / Syst Expert

System / DB Admin

ContractManager

BULL Project Manager

BULL Quality Mgr

BULL TPM*

Senior Business Analyst *

Solution Architect*

Business Analyst

Business Analyst

Business Analyst

DevelopmentManager*

CompetenceCentre

Developers

IntegrationEngineer

DB / Syst Expert

Middleware Expert

End User Training Manager

End User Training Manager *

System / DB Admin

TechnicalTraining

Roll out Support Team Leader

Roll out Support HaythemMosbah

Roll out Support Team Leader*

Roll out Support

Application Support

Technical Writer

Application Support

Application Support

Technical Writer

Application Support

Localization

PMO

Project Assistant

* Team Leaders

-

Senior Business Analyst

Solution Architect

Business Analyst

Business Analyst

.

Business Analyst

CompetenceCentre

Developers

IntegrationEngineer

DB / Syst Expert

System / DB Admin

ContractManager

BULL Project Manager

BULL Quality Mgr

BULL TPM*

Senior Business Analyst *

Solution Architect*

Business Analyst

Business Analyst

Business Analyst

DevelopmentManager*

CompetenceCentre

Developers

IntegrationEngineer

DB / Syst Expert

Middleware Expert





System / DB Admin

TechnicalTraining




Roll out Support




Roll out Support

Application Support

Technical Writer

Application Support

Application Support

Technical Writer

Application Support

Application Support

Technical Writer

Application Support

Application Support

Technical Writer

Application Support

Localization

PMO

Project Assistant

* Team Leaders



The Subcontractor’s Project Manager owns the project management deliverables and is responsible for Project Management. He is the primary liaison with the Contractor’s Project Manager and the Technical Advisor.

The responsibilities of the Project Manager include:

• Coordinate the PMO and all the project management documentation;

• Maintain and update the Project management documents when needed;

• Permanent quality control activity on delegation of the Quality Manager;

• Follow all the actions related to quality assurance as proposed by the project review conclusions and presentation of the quality reports to the Project Operational Committee;

• Planning the work or objectives;

• Preparation of the project plan, and working schedule in conjunction with the Technical Project Manager and Team Leaders.

o Organizing the work o Estimating resources o Assigning tasks o Allocating additional resources;

• Arrange meetings in order to control the overall status, progress and project planning;

• Defining and describing of the overall Contractor’s involvement.

For all the items under Subcontractor’s responsibility:

• Organize all the risk management action plan , assign every risk mitigation plan to a risk manager and control its good execution ,

• Escalate in case of a major problem, suggest and coordinate in the search for the Solution.

• Streamline the issue resolution process.

• Forecast future trends in the project

• Proactively anticipate major project "deviations" and take immediate corrective action.

• Initiate and coordinate meetings with different parties involved in the project, for the purpose of the high-level solution analysis and clarify the overlaps between different parts of the project.

The Subcontractot’s Project Manager reports to the Bull Tax and Customs Competence Center Director.

His main focus will be to provide a quality solution, fitting to contractual commitments in term of content and schedule.

He will manage directly all the functional experts (SBA and BA) and the PMO participants.



Quality Manager provides a quality assurance and quality control function at the project level. His main duty is to monitor the conformity of the project activities with the process and quality procedures through the execution of a predefined quality program of audit and review activities

He will be responsible for:

• Defining the Project quality plan and the quality procedures best suited for the project • Defining the various project committees • Controlling that all the roles and missions of the Subcontractor ‘s project team are

correctly defined (Insuring that all the project members have received a clear statement mission)

• Defining the right level of quality controls to be applied, • Controlling that the quality controls have been performed: quality, project and

technical reviews in line with the Bull System Quality and with the quality control procedures agreed with the Contractor.

• Controlling within the quality reviews, that the Project Manager has permanently checked the correct execution of the quality assurance procedures

• Producing the quality control reports to the Delivery Project Board

He may directly conduct some reviews or work in close cooperation with a Bull Quality reviewer, or the Bull Manager in charge of the Tax and Customs projects.

He reports to Bull (corporate) QA within the Bull International Operations.

Technical Project Manager will coordinate all the activities related to technical design, integration, tests and acceptance, localization, and commissioning.

He is responsible of the following activities:

• Defining all the tasks related to the technical design, integration , testing and implementation of the solution on all the technical environment

• Define the resources needed and assign the tasks to every team member (e.g. organization chart)

• Assist the Project Manager on the project schedule and reporting activities. • Manage as a team leader the software integrator, the localization engineers, the

system and database engineers and all the training activities • Insure the technical project coordination: with all the involved parties, plan and

define all elements needed for the implementation of the proposed Solution • As in charge of the Solution integration, he will report on all the issues,

anomalies, corrections, in order to define the quality indicators • To design the production, development, integration and testing environments.

• To participate to the technical reviews and in jointly with the project manager, he will assign each risk mitigation activity to the best suited risk manager

• Part of the PMO and as such, main provider and controller of all the project management documentation (tests results, acceptance notices, technical reports, ..)

• Permanent member of the POC • Permanent member and secretary of the Change Control Committee



Middleware Expert is a technical architect supporting the project team in order to provide high level expertise on the target infrastructure

• For the lot 003 - IT requirement definition, he will animate a technical committee with the ETA Project team.

• He will take into consideration the ETA horizontal software to define the configuration parameters for FlexStudio run time, and for all the application software data accesses.

• He will define the required production environment and suggest the most adapted configurations

• He can be called as support and advice for o Preparing the integration platform lot 100 o Implementing the prototypes lots 4x0 o pilot and roll out tuning lots 5x0

For his activity related to the project, he reports to the Project Manager.

Solution Architect (BSA) – Is an application architect having high expertise on the e-ris package implementation, on existing modules functionality and on the customization and configuration processes.

• He owns the overall software solution including standard configured modules and customized modules.

• He will study all the translated documents provided by the ETA defining the returns, the fiscal procedures, the assessment rules in order to be ready for making position on the customization.

• He is the main interface of the project toward Bull Tax Competence center and provide to the center the necessary information related to the adaptations in order to obtain from the development manager the detailed implementation plan and specifications.

• He receives from the Senior Business Analysts and Business Analysts the detailed gap analysis; he will analyse this functional gap in relation with the Bull competence centre development manager and will provide rapidly an implementation specification listing all the potential areas which might require some customization.

• He will coordinate the specification document – lot 110 to 190 checking the consistency

• He accepts the delivered software from the competence center and checks that customizations have been correctly implemented and fit to purpose.

• He provides regular status information to project manager • He participates to the functional tests specification

Senior Business Analyst (SBA) The SBA has a long track record implementing integrated tax systems.

• He can provide advices on the best practices.



• He will animate the functional committees and produce the minutes reports • He will produce or validate the functional specifications • He will define the gap analysis with the Solution architect • He owns the functional specification document on the domain or area of expertise. • When the business procedures are not completely defined and leave some open

points, the SBA will be involved to accelerate the decision process and the adoption of the best solution.

He will be involved in the scoping phase and then to supervise the business analysts configuration activities.

The BSA can act also as a business analyst as he knows perfectly how to configure e-ris modules and how to integrate the customization delivery.

The Business Analysts are in charge to

• Specify the business rules, the workflows, the inputs/ outputs. • They will set up all the system parameters with the help of the development

manager: templates of standard letters, structure of the taxpayer notes. • They will participate to the definition and validation of customer acceptance test

cases • They will assist the Contractor for the acceptance tests.

Development Manager (BDM) This profile will been involved in the design and development of the customization of the Bull Tax Application software modules. He knows perfectly how to modify the standard modules to integrate required customization.

• He will be associated as a back office resource to the project in order to support the Solution Architect and the SBA.

• He will deliver the standard modules corresponding to each project phase and will support the project team for all matters related to the installation on the design or integration environments.

• He will integrate the technical configuration parameters defined by the middleware expert

• He will receive and analyse the specification document and the gap analysis • He has the responsibility to define all the customizations and to product a detailed

customization implementation plan • He will manage the developers in charge to apply the changes in the standard

modules • He can be involved to apply a quality control on the localization performed on site

Solution Architect, Senior Business Analysts, Business Analysts and the Development Manager belong to the Bull Tax and Customs Competence centers and for their activity related to the Project, they report to Bull Project Manager.

Technical experts (System and DB experts) belong to Bull Middle East and report to the Technical Manager for their activity related to the project.



They will be responsible for the following activities

• Set up the configuration management system and configure the access rights for all the project’s participants

• Set up the development and integration environments: all the required instances for the Group I, II and III implementation, customization delivery, internal tests, Contractor’s tests and delivery for pre- production environment

• Create the database structures for all the testing or training environments. • Analyze all the data structures provided by the ETA before defining test data into

the integration environment • Prepare the operation procedures with the Development Manager, the Solution

Architect and the TPM • Support the Application Support engineers and the Help Desk engineers for the

prototyping and pilot phases. Application support engineers will apply all the functional tests before solution delivery to the ETA.

The activity will be shared between Business Analysts and Application support engineers in the first prototyping phases and then performed by the Application support engineers all along the prototyping and pilot phases.

They will be responsible of:

• Checking the configuration parameters against the specifications • Checking the applied customization against the specifications • Checking the data base content (data migration or interfaces) • Checking the proposed localization (screens, documents) before delivery to ETA • Supporting the ETA for all the functional tests of the various deliveries (Group I, II

and III) • Support the Help Desk team for diagnosis potential deviation between the actual

functions or parameters and the specifications • Non regression tests after correction patches delivery and integration

They will work closely with the TPM in order to identify potential bugs and submit them to the fault management committee.

They belong to Raya Integration and functionally report to the Project Manager and Solution Architect for their activity related to the project.

Technical engineers (system and DB integration, roll out support) will be associated to the project to operate the following environments:

• Development environment configured by the technical experts and used by all the project team to configure all the e-ris modules and to integrate the customizations

• Integration environment configured by the technical experts and used by the Subcontractor’s business analyst and application support to validate the different stages of the Solution building

In addition they will perform



• Save and restore procedures for all the systems under the Subcontractor’s responsibility

• Initialization of the various DB • Data migration support to ETA • Interface tests • System tests support (performance, load balancing and warm restart )

They belong to Raya Integration and functionally report to the TPM for their activity related to the present project.

Help Desk support Engineers will be assigned to the project from the prototyping up to the ten sites roll out termination

They are responsible of the following activities:

Initiate and supervise the issue reporting system

Support the ETA administrators for issue management and find out immediate turn- around solutions

Support the ETA’s internal Help Desk in charge to collect all the incoming calls from the Tax Office End Users; they will provide a functional and technical support.

The Help Desk Team Leader will start up the Held Desk Support and in addition to the help desk team activities, he will be responsible of reporting to the POC

• Statistics on the end user calls during the pilots and roll out (type, level of knowledge and preparation of the tax office end users)

• Issue management results (pending issues, solved issues) to the POC

He will attend to the change request committees.

End-User Training Manager will be assigned to the project at the time of the start of the training to the trainer program (Lot 400) up to the end of the roll out for the ten sites. He will be responsible for:

• Scheduling training session for end-users in coordination with the project delivery schedule and Contractor’s activities;

• Validating the availability of the premises for training; • Supervising the installation/preparation of the training environment and

material; • Assigning trainers to sessions, control proper execution of the training plan; • Reporting training progress and providing assessment reports to the POC.



Contractor ’s Responsibilities

The Contractor is the owner of the project.

He will be represented by:

• A Project Manager for driving the project from the viewpoint of the ‘owner’. He will be the main point of contact of the consortium project manager. He will coordinate all the activities assigned to ETA personnel.

• A Contract Manager or Technical Project Advisor assigned by Bearing Point / USAID which will supervise the contract execution from the viewpoint of the USAID and will also play as a functional / technical coordinator with respect to the goals and objectives of the TAPR II Program.

The project manager is appointed by ETA Commissioner. He has the authority to run the project on a day to day basis within the tolerances set by the ETA Project Board with principal objective to produce a final product which is capable of achieving the benefits defined in the project scope

His main accountabilities are: - Performs the overall day-to-day management of the project to ensure that project objectives

are achieved within time/cost/quality constraints, whilst managing stakeholder expectations - Initiate and coordinate meetings with different parties involved in the project, for the purpose

of the high-level solution analysis and clarify the overlaps between different parts of the project

- Follow up and coordinate the execution of all project activities and their progress, - Follow up all communications and correspondences in and out the project as he is the focal

point of all project activities. - Directs and motivates the project teams to achieve the all set targets and project’s objectives. - Select and manage the project team; allocate resources for all the activities to be performed by

the Contractor . - Reports project progress to the ETA steering committee and ETA project board to ensure the

project’s overall direction and integrity - Prepare periodical and necessary reports to the executive and steering committee, - Follow up the execution of corrective actions. - Performs management of the risks of the project, including the development of contingency

plans - Escalates in case of a major problem and suggest and coordinate in the search for the solution - Prepare and study change control requests. - Responsible for project completion and production of the lessons learned report In addition, he will insure the validation of all the Subcontractor’s deliveries including the project

plans, the project reports, the documentation and the products.

He will be responsible to communicate internally towards the ETA top management, on the ITMAS project, the followed implementation strategy in order to avoid some external decision may affect the choices made on the ITMAS project.

He will be responsible to obtain the required resources or interfaces for all the works performed by ETA.



Three main teams are under the Project Manager responsibility:

• Functional Team including Functional Integration Consultants and Functional Consultants, which belong to the operational tax authority entities but are reporting to the PM for their tasks related to the ITMAS project

• Project IT Team including the Analysis Team (business analysts), the Development Team (in charge of all potentially required Contractor’s software development in relation with the ITMAS project) and the support team (in charge of the system environment and operation)

• Functional and Key users validation Team

The ETA –TQM, Total Quality Management Committee is responsible to assure that the delivered product meets the set quality objectives and the process development adheres to the development industry standard. Due to the specificity of this project, the committee will collaborate closely to the project manager and will report permanently to him.

If specific audits are requested by the DPB, the audit committee will report directly to the DPB.

The members of the TQM Committee are selected by the ETA IT steering committee.

The committee accountabilities are: - Ensure the deliverables produced by the project meets the user’s requirements. - Ensure the processes involved in producing project deliverables are in compliance with PQP

and other related plans.. - Conduct project’s process audit upon the request by the project manager , POC, or DPB.



The ETA project team

The following chart shows the organization and the reporting of the ETA project team for the ITMAS project execution.

عورشملل ةيهيجوتلا ةنجللاDelivery Project Steering

Committee (DSC)

دقعلا ريدمو ينفلا راشتسملاTechnical Advisor &

Contract Manager

نيمدختسملا نم نييئاصخألا ةعومجمFunctional Consultants &

Functional Integration Team

ةيتحتلا ةينبلا يراشتسأAdvisor; Infrastructure

مظنلا ليلحت قيرفAnalysis Team

مظنلا ةجمرب قيرفDevelopment Team

مظنلا معد قيرفSupport Team

ظنتلا مي الا د يرا مل ش عور م ةنكي ظنلا م ةيبيرضلا سيئرلا ةيم ن ج بنا م حلص ة بئارضلا ملا ةيرص

ETA ITMAS Team Reporting Structure

عورشم ريدم دعاسمAss. Project Manager

عورشملا ةرادا سلجمDelivery Project Board

(DPB)

عورشملا تايلمع ةرادا ةنجلProject Operation Committee

(POC)

ةيسيئرلا ةيبيرضلا مظنلا عورشم ريدمITMAS Project Manager

ةلماشلا ةدوجلا ةنجلTQM Committee

Solid Reporting, & CoordinationAdvisory, Consultancy, Collaboration, Support, & communication channel

يبرعلا فرشأ .د :سيئرلاChairman: Dr. Ashraf Al Arabiعورشملل ةيهيجوتلا ةنجللا

Delivery Project Steering Committee (DSC)

دقعلا ريدمو ينفلا راشتسملاTechnical Advisor &

Contract Manager

نيمدختسملا نم نييئاصخألا ةعومجمFunctional Consultants &

Functional Integration Team

ةيتحتلا ةينبلا يراشتسأAdvisor; Infrastructure

مظنلا ليلحت قيرفAnalysis Team

مظنلا ةجمرب قيرفDevelopment Team

مظنلا معد قيرفSupport Team

ظنتلا مي الا د يرا مل ش عور م ةنكي ظنلا م ةيبيرضلا سيئرلا ةيم ن ج بنا م حلص ة بئارضلا ملا ةيرص

ETA ITMAS Team Reporting Structure

عورشم ريدم دعاسمAss. Project Manager

عورشملا ةرادا سلجمDelivery Project Board

(DPB)

عورشملا تايلمع ةرادا ةنجلProject Operation Committee

(POC)

ةيسيئرلا ةيبيرضلا مظنلا عورشم ريدمITMAS Project Manager

ةلماشلا ةدوجلا ةنجلTQM Committee

Solid Reporting, & CoordinationAdvisory, Consultancy, Collaboration, Support, & communication channel Solid Reporting, & CoordinationAdvisory, Consultancy, Collaboration, Support, & communication channel

يبرعلا فرشأ .د :سيئرلاChairman: Dr. Ashraf Al Arabi



ETA project member missions

Functional consultants Group and Functional integration Group can be nominated by ETA project manager, the End User entities, The Tax integration Project Manager, and the ETA IT Steering Committee.

They are called by the Contractor PM to attend as permanent member or occasional members of the POC and PDB or other Functional committee launched by POC or the DPB.

The functional consultant accountabilities are:

- Facilitate, participate, and approve user requirement definition (High and Detailed levels).

- Approve prototyping and participate to the acceptance process.

Provide directions and participate in the preparation of the test cases

- Participate and approve end user testing.

- Participate and evaluate end user training program.

Provide directions and participate in the data conversion and cleaning process

- Participate in the acceptance of the deliverable products according when is necessary .

- Overseeing the system implementation.

The functional integration consultant’s mission is to oversee the global system covering several functional domains and to check the consistency of the solution from the business and operational viewpoints, in addition of participation and overseeing the above tasks set for the Functional Consultants. They also participate in the quality reviews set by ETA.

The acceptance teams

An acceptance committee can be set up by the POC. It rely on the acceptance teams nominated by the Contractor PM.

Acceptance teams can be formed to conduct reviews and accept the project’s deliveries.

The Contractor PM and Contract Manager are responsible to for the teams after reviewing the needs with the Subcontractor and the DPB/ DSC.

For approving the project management documents, the acceptance team will be composed by:

• The IT Advisor / ETA project manager



• The Technical Advisor / Contract Manager • The Head of Information Sector • The Head of Support team

The following chart summarizes the activities assigned to the ETA personnel

Phase and Activity ETA Typical profile assigned to

Project Management (report validation, project committees, project boards and steering committees)

Project Manager and Project Technical Advisor

Quality assurance Project Manager, supported by IT Advisor (acting quality manager) and ETA quality team.

Scoping and functional specification involvement

Functional Integration Consultants, Functional Consultants, and Technical Advisor (Bearing Point) - as defined in the Contract Exhibit B technical offer section B

Function specification consistency analysis Functional integration consultant, Team leaders of Functional Consultants.

Specification validation Functional Integration Consultant , Contractor PM and CM, Functional Consultants team leaders, and Business Analysts.

Project Environment set-up and organization for all the project participants (Subcontractor and ETA)

Support Team leader

Tests case definition Functional Consultants and Business Analysts

Functional acceptance of prototype Functional Integration Consultant and Functional Consultants, Business Analysts.

Data preparation Functional Consultants and System Support Team Leader

Production environment set up and operation System Support Team Leader and Central operation system administrator.

Interface alignment Project Team Business Analysts and System Support Team Leader

ITMAS administration after pilot commissioning

Central Operation Department and System Support Team.

ITMAS user management Central Operation Department and System Support Team.

ITMAS pilot acceptance Functional Integration Consultants; Functional Consultants

ITMAS Roll out acceptance PM + Project Technical Advisor (and CM), Functional Integration Consultants; Functional Consultants

System administration, back-up, recovery and security, operational support

Project Support Team, Central Operation Department



Quality Assurance Organization The following missions will be in place to insure the Project quality assurance and control. They are in line with the Subcontractor’s commitment to quality. They are independent of any complementary activity planned by the Contractor to anticipate on any project risks (linked or not to the subcontractor’s activity ) and to check the level of quality of the project deliverables. Profile Role Tasks

Project Managers (Contractor and Subcontractor)

Responsible for the daily management of actions regarding overall contractual quality assurance subjects

Supervision of the Quality Assurance process.(Quality indicator follow up) Risk Management Initiate and assign tasks to the Change Control Committee Issue request to the QM for the quality control (audit, reviews) in case of detecting new risks on the project. Propose / control changes to the PQP and associated plans

Quality Manager (Subcontractor)

Overall responsibility for the project Quality Management and Quality Assurance procedures of Project deliverables

Define and maintenance of quality procedures, quality control, review, audits and inspection, , co-operation with Bull corporate quality assurance, Selective Reviews of the Project Documentation

TPM and Solution Architect (Subcontractor)

Responsible for daily management of quality assurance in the field of analysis, functional specifications and testing

Quality control of project deliverables. Checking the quality of deliverables to ETA through internal testing (for the application software) and reviews (for the application documentation - Specifications, logical architecture, test specifications)

Development Manager (Subcontractor)

Responsible for daily management of quality assurance in the field of management of the software development team and technical documentation

Checking the conformity of the activities of the software development team to the pre-defined process and project plan, validating the internal deliveries to the Subcontractor's testers for internal testing, review of the technical documentation



PROJECT MANAGEMENT STRUCTURE Project management structure includes all the shared committees and the decision process related to the project events.

The proposed structure follows the Bull MOSICTM methodology itself with the Project Management Institute (PMITM) set of standards.

Principles of Project Coordination Several committees are planned for the Project coordination, in order to monitor the Project execution and to present the Project progress to the Contractor and Subcontractor Management executive levels.

The management structure will be used to measure the Project performance, to solve all the issues related to staffing, environment, project scope, changes and internal communication.

All the management committees are scheduled by the Contractor and Subcontractor Project managers and the contract managers.

The committee frequency is defined at the project initiation phase, taking into account the necessary working period for processing the actions assigned during the previous committee..

Other meetings, workshops, or technical committees are also planned to coordinate the technical and functional design, the data migration process, the solution acceptance tests. These committees are launched by the Project Operation Committee.

The following chart shows the different committees planned for the Project.



Project Operational Committee

The Project Operational Committee (POC) is responsible to supervise the day to day delivery of the project delivery such including but not limited to overall systems design, e-ris customization, integration, testing, pilot implementation, roll out of the system, end user and technical training..

The Committee is composed by following permanent members:

• Contractor Project Manager, chairman of the POC • Bearing Point Project coordinator, deputy • Raya contract manager • Bull Project Manager, POC secretary, in charge to define the POC agenda and to

prepare the POC meeting minutes. • Bull TPM

Bull project Manager will act as Quality Manager if the later is not present.

Regular POC meetings are planned every two weeks. Exceptional meetings can be called by the Chairman upon request of PMs or other permanent members of the Committee.

In addition to the permanent members, other members, involved in the project or subject matters specialists from ETA will join up the POC or be invited on specific meetings:

• Head of Analysis team • Head of support team • Head of Development team • Functional Consultancy Group team leaders and members, • Functional Consultant team members , • IT Advisor acting Quality Manager • IT Responsible.

The list of the POC members and the distribution list of the POC minutes are attached in PQP appendix A .

According to the meeting agenda, members from the functional teams and advisor as well as members of the technical teams can be invited to join the POC meetings if they are needed to present positions or make proposal on a specific question such as technical or functional committee report.

The Subcontractor PM can also invite any project team leader member, to explain a specific technical, functional or organizational item.



The POC minutes will be distributed by the Subcontractor PM, within three days after the POC to collect remarks or modification requests. The final report should be distributed within 5 days after the POC and formally approved when starting the next POC.

Standard POC agenda and report structure can be established jointly at the project launching.

Delivery Project Board

The Delivery Project Board (DPB) is responsible for review of the project progress, and has a coordinating, monitoring , quality assurance and conciliation role. The board provides authorization of any changes to project scope (deliverables, resources, schedule), which not affect overall business objectives. The DPB takes project related or technical decisions with the participation of the experts when necessary and reports to the Delivery Steering Committee.

The DPB is the first level in problem escalation path.

Regular meetings are planned every six weeks. Exceptional meetings can be called upon the request of PMs or other members of the board.

The DPB is responsible for: - Monitor and follow up the projects activities against the project plans by conducting regularly

project status meetings . - Monitor the progress and quality assurance reports including the risk mitigation reports, and

identify actions to improve the performance or to reduce risks - Identify and handle implementation constrains. - Drawing the attention of the Project Managers to cases where the project teams fail to meet

their commitments. - Resolve technical conflicts between project teams by using technical experts in the conflict

domain. - Decide upon any significant changes in the resources, the work plan or the project scope. For

each point, the party submitting the request, should present its plan and rational for change. - Receive and study change control requests utilizing and sourcing specialized resources

required to do the study and prepare related reports. - Analyze the reports and if needed, decide to present the changes impacts to the steering

committee with recommendations and get its decision on the requested changes. to accept or otherwise.

- Formally recommend the acceptance of deliverables to the management board;

The DPB will be the first level of the escalation process. All issues not solved at the level of the POC, can be submitted by one of the parties to the DPB. The DPB permanent members will work in order to find a solution which could be accepted by both parties. The DPB can also decide to escalate the identified issues to the steering committee if necessary and get the appropriate directions. that need steering committee influence to be handled.



As described above, the DPB should focus the attention to project progress between two meetings, the issues raised during the period and on the quality controls and risk analysis.

As presented into the quality control management, the DPB should follow a Subcontractor’s project review ( Bull standard BCR, or a quality / project review planned for the purpose) and the resulting risk management plan and recommendations will be presented during the DPB.

Contractor’s can decide also to set up a review related to the performance of the ETA team to complete activities related to the project.

The output of the reviews should be presented to the DPB in order to decide upon the action plan for improving the project performance.

The DPB will be called by the POC at least 15 days before its effective date.

The meeting’s agenda will be prepared jointly by the Contractor’s and Subcontractor’s project managers and contract managers. The minutes of the meeting will be prepared by the Subcontractor’s project manager and will be distributed for approval to the participants within 5 days from the meeting’s sessions.

The permanent members of the DPB are:

For the Contractor:

ETA Head of Information Sector

ETA Head of IT Central Department, Sales Tax

ETA Commissioner IT Consultant

ETA, Head of Survey Central Department (Income Tax)

ETA, General Manager, LTC Computer Centre

ETA IT Advisor – IT Program director (Acting Quality Manager)

ITMAS Project Manager

Bearing Point Contract Manager

Functional Integration Group Domain Experts

For the Subcontractor

Raya Project Management General Manager

Raya Project Management Manager – Government sector

Raya Contract Manager

Bull Middle East General Manager

Bull Business Application VP

Bull Project Manager

Bull Business Application VP will act as Bull Quality Manager if not present.



Project Steering Committee

The Delivery Project Steering Committee (DSC) is responsible for providing the overall business directions of the Project, defining and realizing benefits, monitoring identified and reported risks, authorizing to proceed to next phase.

DSC plays an active role and includes ensuring that the project always makes sound business sense, involving all parts of the organization which benefit, engaging stakeholders, approving key deliverables, giving direction and when required making decisions or recommendations at key moments in the project’s life.

DSC is the highest level in problem escalation path and provides direction in the conflict resolution process.

The DSC accountabilities include: - Review & approve project scope & schedule. - Steers the project through the business environment for changes which may impact the

viability of the project - Provides direction and guidance on matters of policy - Approves all major plans and authorises any major deviation from agreed plan - Negotiates a solution to any problems between the project and external bodies - Set and Ensure achievement of project’s objectives upon end users requirement. - Signs off the completion of each stage and authorises the start of the next stage - Take decisions regarding process reengineering. - Approve change control requests and including any change in project scope. - Ensures that the required resources are committed - Facilitate resolution of any problems, difficulties, and handling of risks. - Propose solution to any conflict within the project - Approve initiation of any new project.

The DCS will have regular meetings during all project duration. Regular meetings will be held quarterly, however ad hoc meetings could be called upon the request of the chairman of the DCS or the Subcontractor permanent member in the DSC to present an escalation issue not solved by the DPB.

The DPB can be replaced by a DSC if needed by the project progress , through the participation of additional members and previous notice sent to all the attendees .

The DSC will be chaired by the Head of Tax Authority ( General Commissioner) and composed by members from the Contractor and senior representatives from the Subcontractor consortium (Raya and Bull).

The Contractor DSC Members are

Deputy Minister for Tax Policy - Tax Commissioner

Assistant Minister for IT



Advisor to the Minister, IT and Tax Integration PM

Bearing Point – Managing Director

Bearing Point – Technical Advisor and Contract Manager

Head of Information Sector

Head of LTC Sector

Head of MTCs Sector

Head of STCs Sector

ETA Project Manager

Advisor IT, IT Program Director

For the Subcontractor

Raya Chief Operations Officer

Raya Project Management General Manager

Raya Project Management Manager – Government sector

Raya Contract Manager

Bull Middle East and North Africa General Manager

Bull Middle East General Manager

Bull Business Application VP

Bull Project Manager

The agenda and minutes of the meetings, will be prepared jointly between Contractor Project Manager, Raya Contract Manager and Bull Project Manager.

The prepared reports on the minutes of the meeting will be sent for approval within 5 working days from the DSC meeting session.

Project Technical (functional) Committee

The technical and functional committees will be set up for the matters requiring different skills and people from several origins:

• Technical infrastructure definition (business applications, servers, network, tools)

• ITMAS operation definition (business applications, tax schedule, IT administration)



• Data migration definition (existing systems, Bull Tax Application data structure, tools)

• Global functional definition (cross-domain)

• Tests scenarios definition (existing data, Bull Tax Application modules, business practices)

• Roll out preparation (key end users, training people, IT administration)

• Change request committee (called also Change Request Board)

They are complementary to the technical and functional workshops gathering experts or consultants working in a single domain and having to analyze and clarify the Project scoping and prepared the detailed specifications.

The technical and functional committees are assigned by the POC with given objectives and duration.

Contractor PD and Project Manager will determine the participants, assign a leader or secretary in charge to produce the minutes and to report the results to the POC.

The committee leader will receive a letter of mission in which the expected outputs will be clearly defined.

The committee creation chart will include the list of the permanent members, and the expect period and workload for each of them.

The committee will organize itself in term of schedule, working methods and validation process.

The intermediate reports will be distributed to the committee permanent members who will validate them within two days. Escalation Procedure The proposed committees will facilitate the ‘escalation procedure’ and reduce the delay to solve any pending issues.

The POC is the main instance for each party, the Contractor or the Subcontract to present formally an issue blocking the project execution.

This issue should appear clearly into the POC agenda and both PMs and CMs must focus on find a solution before the next committee.

If one of the parties, doesn’t get any answer to an issue or alert presented at the previous POC, within the delay allocated to get it solved, the Contract Manager of this party can alert by mail the other party permanent executive member belonging to the Project Board.



This alert will be sent officially by mail with copy by email to both PMs.This alert must describe the issue and the expected position or action from the other party and will propose an action plan:

• Give an additional delay for getting the problem fixed • Modify the schedule and the activities waiting for the issue resolution • Call for an anticipated DPB or DSC

If despite this DPB session, the issue is still pending after 10 days, the party can submit it to the other party’s DSC member

The DSC Contractor’s and Subcontractor’s permanent members are subject to decide upon the issue and to provide a recommended solution.



Project Milestones and deliveries

ITMAS project is planned through a phased delivery approach:

• Phase 1: Analysis and Design • Phase 2: Development, implementation and pilot of the core functions (Group

I) at the LTC site; • Phase 3: Development, implementation and pilots of other functions (Group II

and III) at 2 sites (LTC and MTC); Deployment to 10 district offices (5 MTCs and 5 STCs).

The scope of the project is divided into Lots. Each Lot is a combination of products and services to be delivered together by Bull. All the lots have deliverables, installation and test and acceptance activities. Each lot has its own terms and conditions.

PROJECT PHASES Major milestones of ITMAS project

The ITMAS solution has been segmented into the following groups: Group I

o General requirements; o Registration; o Processing of documents (Returns and other documents); o Processing of payments; o Taxpayer and Revenue Accounting;

Group II o Audit o Enforced Collection; o Control of Stop-filers and delinquent taxpayers;

Group III o Taxpayers service; o Appeals (Objections); o Archive management;



o Management Information System.

Delivery Segmentation

The scope of the project is divided into Lots. Each Lot is a combination of products and services to be delivered together by the Subcontractor. The Lots all have delivery, installation and test and acceptance activities. Each lot has its own terms and conditions.

Lot Ref Lot Name Phase Func. Group

Initial schedule for

end of lot

Lot 001A Project Setup 1 18/11/2007

Lot 001B Project Management All

Lot 002 Define Business Areas at ETA stand point 1 18/11/2007

Lot 003 IT requirements definition 1 20/01/2008

Lot 010 Scoping Control Area 1 9/12/2007

Lot 020 Scoping Registration Area 1 9/12/2007

Lot 030 Scoping Assessments Area 1 9/12/2007

Lot 040 Scoping Revenue Accounting Area 1 13/01/2008

Lot 050 Scoping Enforcement Area 1 20/01/2008

Lot 060 Scoping Taxpayer Audit Area 1 3/02/2008

Lot 070 Scoping MIS 1 3/02/2008

Lot 080 Scoping File & Document Control Area 1 3/02/2008

Lot 090 Scoping Appeals and Objections Area 1 3/02/2008

Lot 101 Detailed Plan for integration 2 30/12/2007

Lot 100 Prepare Integration Platform 2 9/03/2008

Lot 110 Integration Control Area 2 IA 8/06/2008

Lot 120 Integration Registration Area 2 IA 8/06/2008

Lot 130 Integration Assessment Area 2 IB 31/08/2008

Lot 140 Integration Revenue Accounting Area 2 IB 14/09/2008

Lot 150 Integration Enforcement Area 3 II 26/10/2008

Lot 160 Integration Taxpayer Audit Area 3 II 21/12/2008

Lot 170 Integration MIS 3 III 28/12/2008

Lot 180 Integration File & Document Area 3 III 16/11/2008

Lot 190 Integration Appeals and Objections Area 3 III 9/02/2009

Lot 300 Standard Software (Crystal Reports) 2 27/04/2008

Lot 400 Training to Trainers and IT 2 23/11/2008

Lot 410

Prototyping

Prototyping 410A

Prototyping 410B

2 and 3

26/10/2008

28/12/2008



Prototyping 410C 22/02/2009

Lot 500 Pilot Preparation 2 and 3 2/11/2008

Lot 510 Data Migration 2 and 3 28/06/2009

Lot 520 Training 2 and 3 28/06/2009

Lot 530 Pilot 1 (LTC Site) 2 12/04/2009

Lot 540 Pilot 2 (MTC site) 3 24/05/2009

Lot 550 System Roll-out to 10 sites 3 30/08/2009

The Appendix C describes for each lot:

• its definition; • the prerequisites to start the Lot; • the list of deliverables (Documents, Software, Training); • the list of activities to be performed to deliver the Lot, including the WBS of the Lot. It

should be noted that inputs required to deliver the Lot will be identified as Milestones; • Contractor and Subcontractor responsibilities for each of the above activities; • the summary of Test and Acceptance Milestones for the Lot;

However the Subcontractor’s deliverables do not cover the following areas:

a) Technical Infrastructure, including Network communication, hardware procurement, installation and implementation,

b) The backup of operating systems, databases, and the Bull Tax Application Software Package (the subcontractor will provide backup procedures for the tax system),

c) The purchase and licensing of operating systems, databases, network management tools, anti-virus tools, utilities and other application software not supplied by the Subcontractor,

d) Taxpayer and other financial data preparation and cleansing, including the computation of account opening balances,

e) Preparation and formatting of data in external applications, as well as the development of tools within such external systems to provide the required data into the tax application,

f) The capture and registration of ETA users into the Application System Software,

g) The supply of project management tools and office automation tools to ETA, h) Business Process Reengineering services, i) Changes in Operational Procedures.

DELIVERABLES AND PROJECT DOCUMENTATION The project documentation will be stored into a shared server.

The following chart summarizes the project management documentation required to follow Bull Quality System Standards (ISO Compliant).



This documentation will be referenced as per definition into the Documentation Management Plan.

All the versions will be journalized and their status clearly identified in the cover page ( draft to be completed, complete version under validation, version under revision, approved document).

The Project Management Office will keep updated the archiving system on which all the documentation will be stored.

The access rights will be defined by the Subcontractor’s Project Manager.

Some repositories will be given access to the project stakeholders

DOMAIN DOCUMENTS

General Master Project Plan and Subsidiary Project Plans by axis as requested.

Project Charter

Contracts Main Contract (Raya – BP)

Sub-Contracts (Raya - Bull)

Exhibits – RFP - BAFO- Scope of Work

Project Management (Project monitoring)

Project Plan with the Gantt Charts (living part of the PQP), POC reports, the Minutes of the POC Meetings and the Documentation Summary, i.e. the list of all documents to be produced during the project and their status. Technical and functional Committee’s reports

Project Quality Plan Contains all versions of the PQPs and the glossary; defines the Contractor Organization and Raya -Bull project organization. Standard Forms

Project Deliverables Structured description of Extent of Supply

Project Work Breakdown Structure

Project WBS

Project Organisation structure

Project Organisation (OBS, RAM)

Project Team Terms of Reference (with project team directory)

Project Planning Project Planning Schedules

Project Communication Review schedule

Project Management Reports : DPB and DSC reports

Meeting Minutes with action list

Documentation plan

Release documentation

Risk Management Risk SummaryRisk Records

Change Control Summary file

lists all the submitted Change Requests with their status

Testing and Acceptance Acceptance Specifications



Process Testing and acceptance plan

Delivery records

Acceptance Certificates

Configuration Management Configuration Management Plan

Support Support Plan

Support SLA

The technical documentation consists of the following: • overall system architecture (logical, technical services);

• build Documentation;

• Administrators Handbook including how to implement new module versions, and generating a new global version for maintenance purpose (update, corrections)

• Installation instructions and release notes

The end-user documentation consists of: • user manual and help files for the application software per module covering

different profiles of users (written in English and translated to Arabic after being accepted by the Contractor);

• Training materials for application software per module as a help tool for the course.

For all the other deliverables (programs, utilities, ..) the Appendix C will describe for each lot, the list of the deliverables.



Quality Procedure and Quality criteria

According to its category, each project deliverable is verified against pre-defined characteristics to check its quality. The following table gives the reference of quality procedures and quality criteria for each type of deliverables.

Bull's Deliverable

Quality procedures

Where documented Quality criteria

Application SW Delivery Agreement Conformant

Application Software Development Tool

Installation Technical Specification Conformant

Acceptance Test & Acceptance Plan;

Technical Specification

Conformant

Timely delivery and approval

Documentation Documentation standard

Documentation Plan Conformant

Documentation review and issue process

Documentation Plan Conformant

Documentation approval

Documentation Plan;

Test & Acceptance Plan

Conformant Timely approval

Application Standard e-ris delivery Agreement Conformant

Timely delivery and acceptance

Standard e-ris installation

Test & Acceptance Plan;

Installation Specification

Conformant

Timely installation and acceptance

Integration/functional acceptance of adapted e-ris V3

Test & Acceptance Plan;

Test specifications

Conformant

Timely acceptance

Training Prerequisites skills description

Training Plan Conformant

Courses content Training Plan Conformant

Designation of trainees Training Plan Timely Designation

Training acceptance Training Plan Training Reports;

Timely acceptance

Prototype Prototype acceptance Implementation plan for prototype

Test and Acceptance Plan

Conformant

Timely acceptance

Pilot Pilot acceptance Implementation plan for pilot;

Test and Acceptance Plan

Conformant

Timely acceptance



Quality control management

Principles

Quality control will apply on all the project activities and need to cover:

• Project management activities • Solution design and building • Solution implementation and roll out

Each domain will be controlled over a set of methods and standards previously adopted by the project teams and communicated to the project participants

Domain Areas subject to control

Adopted methods and standards

Type of controls

Project Management

Project monitoring PMI and MOSIC Project committees

Quality indicators on the project monitoring

Project reporting PMI and MOSIC Project Mgt reports

Quality indicators on the project reporting

Quality assurance procedures

MOSIC procedures (PQP and associated plans)

Quality reviews

Risk management MOSIC procedures (PQP) Project reviews

Quality assurance procedures

MOSIC procedures (PQP and associated plans)

Quality reviews

Solution Design and building

Scoping and specification Proposed methodology

UML standards

Project reviews on site

Documentation review

Customization e-ris standards for customization

J2EE and Java standards

Technical reviews on the competence center

Quality indicators

Risk portofolio

Software integration MOSIC integration plan

J2EE deployment

Proposed test methods

On site technical reviews

Quality indicators

Risk portofolio

Interface management MOSIC integration plan

Test plan


Quality indicators

Risk portofolio

Solution implementation and roll out

Data migration Proposed methods on the data migration plan


Quality indicators

Risk portofolio



Tests (functional and global)

Test plan (including MOSIC and e-ris best practices)


Quality indicators

Risk portofolio

Functional training and end user training

Proposed training plan Project review

Quality indicators

Operation and roll out Proposed operation plan and support plan

Project review

Quality indicators

The present chapter will present the proposed quality controls.

The proposed quality control plan take into account the MOSIC reviews (BCR) which are mandatory to the Bull project team and the reviews which should be planned accordingly to the ITMAS project management committees. The quality control plan is described at the end of the present chapter.

Project monitoring and reporting

The project is structured into a set of Lots/Work packages in a Work Breakdown Structure.

Project control is performed by the Lot/Work package responsible on their respective tasks and reported to the Project Manager in the Project Office.

Project reports A list of standard reports is being agreed upon with the Contractor during the first POCs. A preliminary POC status report has been annexed to the PQP and it will been completed after the Project initialization phase (Lot 001A) to include the change request decision chart, and the fault management status chart. The POC status report should be used to monitor the project execution. It must include the following information

the list of actions posted during the last meeting with their status (open, closed, pending) the current and planned activities for each subproject : software customization, infrastructure

delivery and installation, tests, operational support, training, and bug corrections the consolidated work plans and master schedule with indication of any major changes the list of the system change requests for decision the system error reports and actions for correction the technical and operational support reports

A periodical focus (monthly meetings or before the Project Board) will be organized for

Analyzing the quality indicator reports The risk factor portfolio and associated mitigation

The project reports are prepared by Bull PM and is supplied to the Contractor Project Manager and other participants three working days after the POC, along with the next meeting schedule agreed during the POC.

Project reports are always in English.



After a project board meeting, a progress Project report will be prepared by the Bull PM, and validated by the contractor’s Project Manager before distribution. This progress project report extends some of the aspects of the standard POC minutes report.

It contains a description of achievements, key pending problems, mid-term actions and activities and an update of the global project plan.

Progress Reports are always in English, and will address the following topics: • progress measurement:

a list of milestones achieved during the last reporting period, against plan a list of milestones scheduled for the last reporting period, but which were not achieved, against plan; a list of milestones scheduled for completion during the next reporting period; a summary of deviations and adjustments, and reasons

• problems and issues; a description of problems or other occurrences that are putting at risk the achievement of milestones;

• quality management: a summary of the quality actions carried out during the last period and their results;

• risk management: an identification of any new potential risk and possible mitigation, and a summary of the of risk management to date.

• action list: a list of actions to be taken, decisions that have been taken, information that has been given;

• change status: a summary of requested, approved, and completed scope changes;

• updated Project Plan (Gantt chart) .

Quality indicators A set of quality indicators will be progressively defined by the POC updating the following list.

Area Description Criteria and measurement Quality procedures respect

Main quality procedures are : configuration management Incident management Change management Keep the operational quality processes.

Number of violation of the quality procedures (non identification of documents) Lack of minutes Delay on answering to a project management request

Schedule respect (Subcontractor)

Keep initial milestone for all intermediate deliveries

Number of cumulated items on delay Variance of schedule delays

Validation delays by Contractor

Keep the adopted validation delay for each kind of delivery : reports, specification note, programs, data base

Number of items for which the standard validation delay has not been respected



migration Number of cumulated days of delay during a given period (month, quarter)

Development environment availability

Up time of the environment Number of interruptions per month and quarter ; number of hours (working hours) without access to the development environment

Production environment availability

Up time of the environment Number of interruptions per month or quarter impacting the tests or the system acceptance

Project reviews

Project reviews are the main quality control process for the Project.

Most of the reviews are internal to the subcontractor in order to check the project progress, the software specification and delivery, the risks associated to the environment, to the resources.

Generally these internal reviews are scheduled before Project boards in order to get involved the subcontractor management in the conclusions and in the correction plan.

Some reviews will be shared between the Contractor and the Subcontractor in order to get a clear understanding of the project overall risks including the roll out.

ETA may also conduct quality reviews upon the request of ETA contract manager or ETA project manger. The quality control scheme is internal to ETA and do not constitute a part of the quality procedures owned by the Subcontractor, and will not impact Subcontractor activities.

Subcontractor Quality reviews Project related Business Commitment Reviews (BCR)

These are decision meetings to check that all required project tasks have been carried out correctly, that all associated risks have been identified, analyzed and assigned to an owner for action and to examine the projects business and financial situation.

Within the eight BCR points within the MOSIC™ process, three key BCRs will be applied to the Project: end of conception BCR2, software delivery phase BCR3 and pilot status review before deployment BCR5.

These BCR reviews are conducted by the Project Manager and the Quality Manager.

The Contractor will be informed of the BCR results.

Technical reviews

The technical reviews will be applied before the software delivery. These reviews will provide evidence to identify that, the software product conforms to its specifications and adheres to regulations, standards, guidelines, plans, and procedures applicable to the project.



Software Products subject to Technical Review

The software products subject to technical review include, but are not limited to:

• Software requirements specification for customizations; • Software design description for customization; • Software product Technical documentation; • Software test documentation; • Software user documentation; • Software administration and Installation procedures; • Release notes.

Input to Technical Review

Input to the technical review shall include the following items

• A statement of objectives for the technical review; • The software products being examined; • Software project management plan; • Current anomalies or issues list for the software products; • Any regulations, standards, guidelines, plans, and procedures against which the

software product is to be examined; • Documented review procedures.

Goals of the Technical Reviews

During the technical review, the review team shall hold the meetings and will evaluate the software product and anomalies; He will check

• the software product is complete; • the customization and changes have been properly implemented and affect only

the specified areas; • the software product is suitable for its intended use; • it has been deeply tested and no anomalies are pending • the documentation has been updated to carry on the customizations and changes

Outputs of Technical Reviews

The output from the technical review shall consist of documented evidence that identifies the readiness of the software product to be delivery or the action plan to recover the pending anomalies and the issues related to the scope, deviation to specification, incomplete documentation.

The technical review shall be considered complete when the activities listed above are accomplished.

Joint Program/Project Review This review assesses and examines the status of all parties’ commitments and monitors progress, risks and change requests. Contractor will participate in this review to contribute information concerning the status of their risks and commitments, as well as to be kept informed about the project’s progress.

These reviews are conducted jointly by the Subcontractor and the Contractor.



The decision to set up this joint review can be made during a Delivery Project Board in order to anticipate potential risks on resources (for getting the acceptance, or the roll out) or on the workload (due to project schedule constraints and potential slippage).

Technical Implementation Review This is an independent review to assess and validate the architecture and technical implementation of the application.

These reviews must be conducted by specialists other than the authors of the application but the degree of formality applied will be dependent on the project requirements.

The output from the technical review shall consist of documented evidence that identifies the project being reviewed:

• the review team members, • the software product reviewed, • review objectives and whether they were met, • a list of resolved and unresolved software product anomalies, • a list of unresolved system or specification action items, • a list of management issues, action item status (open, closed), ownership and target

date (if open), or completion date (if closed), • any recommendations made by the review team on how to dispose of unresolved

issues and anomalies, • whether the software product meets the applicable regulations, standards,

guidelines, plans, and procedures without deviations. Review of Acceptance Activity and Procedure Reviews of the acceptance process can be required if it appears that the acceptance schedule is at risk and that the TPM and the application support team detect some discrepancies between the acceptance procedure and the readiness of the components (full software availability , data migration, tests plans, tests scripts and data)

The review can be managed by an external reviewer (from Subcontractor ‘s competence centre).

The analysis will cover:

a) Completion of each Lot; b) Technical Implementation Documents Review; c) Acceptance Test Specifications and Test Cases Review; d) Installation Report Review; e) Contractor’s Data Readiness Review; f) Contractor 's Environment Readiness Review; g) Acceptance Test Reports Review;

The review should identify potential areas of progress.

Output of the review will be presented to the Contractor during the Delivery Project Board.



Audit The Audit is an exceptional procedure, to be activated when all other processes and reviews listed above have not permitted to resolve an issue.

The purpose of software (solution) audit is to provide an independent evaluation of conformance of the software product and procedures to applicable regulations, standard, guidelines plans and procedures.

An ‘internal’ audit can be decided by the Subcontractor’s Management after a Delivery Project Board or an Internal Quality review showing unacceptable risks.

A Contractor’s audit can be decided after a Delivery Project Board or a Steering Committee, upon the conclusion of solution non compliance with the quality standards or the specifications.

ETA might have their own Audit definition and policies differ from what stated in PQP. ETA audit processes are not part of the project audit procedures, however ETA contract manager or ETA project manager may request audit process to be conducted by ETA personnel, this should not impact Subcontractor activities. Subjects of Audit

The software products subject to audit include, but are not limited to, the following technical documents and technical records:

• Software project management plan for customizations; • Implementation plan; • Software quality assurance plan for customizations; • Software configuration management plan ; • Software design description for customizations; • Software requirement specifications for customizations; • Software product Technical documentation; • Software test documentation; • Installation plan; • Installation procedures; • Reports and Data (i.e. review, audit, project status, anomaly reports, test data) • Standards, regulations, guidelines and procedures; • Management review reports; • Technical review reports; • Inspection reports; • Operation and user manuals; • User documentation; • Vendor technical documents;

Decision for Audit

The need for an audit may be established by one or more of the following events:

• Subcontractor decides to verify compliance with the specifications or with the quality standards

• Contractor decides upon the need to audit the software product to verify compliance with application regulations, standards, guidelines, plans and Procedures.

An audit shall be conducted only when the objectives of the audit are clearly defined.



If the audit is asked by the Contractor, the workload and impact to support the audit should be defined and agreed before its performance.

Audit Plan

The audit plan shall be agreed by the Contractor and the Subcontractor Management.

The audit plan should allow for changes in the audit plan based on technical information gathered during the audit, subject to approval by the interested parties.

For a Contractor’s audit, the plan shall be provided to the Subcontractor at least 5 (five) working days before the start of the audit. Any proposed change made in the audit plan shall be agreed with the Subcontractor at least 2 (two) working days before being effective. Output of Audit

The output of the audit is the audit report. The audit report shall contain the following:

• Purpose and scope of the audit; • Evaluation criteria; • Summary of examination activities; • Summary of the planned examination activities not performed; • Observation list, classified as major or minor; • A summary and interpretation of the audit findings including the key item of non-

conformance; • The type and timing of audit follow-up activities; • Audit checklist.

The Audit shall be considered complete when the activities listed above accomplished.



Project risk management Risks are defined as events or situations that, if not addressed, may adversely affect the project or system under development.

Bull uses the Program Risk Analysis and Management (PRAM) methodology as part of MOSIC™. The PRAM approach to risk, focuses attention continually on risks and the identification of ways of abating them. Risks are highlighted at all the major lifecycle reviews and checkpoints.

The PRAM risk management cycle is illustrated below:

Risk Management The purpose of risk management is to identify, quantify, control and eliminate (if possible) all risks which could jeopardize the successful completion of the ITMAS project.

The tasks involved in the management of risk are: • identify the risks and record their details;

• quantify the risks - determine their impacts, probability and severity;

• organize the risks into groups and assign owners (and actions)

• prepare a Risk Management Plan for the significant risks - decide what to do and when;

• monitor the activities at risk;

• initiate contingency plans whenever necessary

• periodically re-assess the risks, determine conclusions from the experiences and refine the associated processes .

A risk portofolio will been established periodically by the Subcontractor Project Manager, as the result of the various project reports status, the evolution of the quality indicators, the fulfillment of the workplan by all the project stakeholders.

Identify

Quantify

Organise &Solve

Plan&

Decide

MonitorAction &Control

UnderstandAnalyse &

Communicate

IdentifyIdentifyIdentify

QuantifyQuantifyQuantify

Organise &Solve

Organise &Solve

Organise &Solve

Plan&

Decide

Plan&

Decide

Plan&

Decide




UnderstandAnalyse &

Communicate

UnderstandAnalyse &

Communicate

UnderstandAnalyse &

Communicate



Risks will be classified by nature.

A risk portfolio template is attached to the PQP; it is based upon the following information:

Ref. Risk Description Impact Countermeasures Risk Assessment

Monitor

Countermeasure Responsibility

Risk Management Structure

For the ITMAS project, the risk management structure will be initialize by the Quality Manager with the help of the Contractor Project Manager and Bearing Point contract manager.

Almost risks are identified during the project quality control reviews.

A preliminary risk portfolio will be established and presented to the POC as part of the communication process and in order to share the position between the parties.

The inventory of the risks will be done with the POC session specifically dedicated to the quality indicator. Risk analysis will be completed within the following framework:

• Description of Risk;

• Risk Owner;

• Severity;

• Urgency;

• Review Period;

• Mitigation Strategy and Action Plan.

Risk Activities Assessment Both parties, the Contractor and Subcontractor shall combine theirs efforts to solve these risks.

The sharing of responsibility for these risks and a common understanding between the parties is critical for the success of the project.

The risk portfolio will be reviewed periodically (on the monthly basis) by the POC permanent members or by default at each Delivery Project Board.

Bull Project Manager will evaluate the risks with his team leaders and will be advised by the project quality manager on the way to mitigate the risks.

The risk will be assessed and the action plan defined in order to mitigate the risks.

The results of these sessions are described in the Minutes of the Risk Management Meetings and are part of the project documentation.



Each identified risk will be assigned to a risk manager who will be responsible of all the actions needed to mitigate the risk

By default when no risk manager has been clearly identified in the risk management report, it is assigned to the Project Managers.

The following chart shows a potential activity assignment (Bull PRAM Method) related to risk management.

Risk Identification and Assessment

Task Participants

State the techniques that will be used to identify risks at the beginning of the project and on an on-going basis (e.g; during Project Status Reviews). This may involve a formal risk assessment workshop, a brainstorming session, interviews, etc. Describe any consolidated lists of generic risks or risk factors that will be used to identify candidate risks for this project.

Bull PM, Bull QM

Risk Quantification

Task Participants

The Risk Manager , PM by default will estimate for each risk its probability and impact, with involvement of project members.

Risk Manager/Owner and Project Members

The individual analyzed risks are collected, reviewed, and adjusted if necessary. The risks are documented and sorted by risk exposure (probability times impact).

Risk Manager/Owner

If the project planning activities will incorporate schedule or budget contingencies based on risk analysis, describe the process of estimating such contingencies and communicating the information to the Project Manager or building those contingencies into the project schedule here.

Selected project members

Risk Response Planning

Task Participants

The risks are assigned to individual project members for development and execution of a risk mitigation plan. <Or, a group brainstorming session is used to define mitigation plans for individual risk items and to assign responsibility to individuals.>

Risk Manager/Owner,

For each risk factor, recommend actions that will reduce either the probability of the risk materializing into a problem, or the severity of the exposure if it does. Return the mitigation plan to the Risk Manager.

Risk Manager/Owner

The mitigation plans for assigned risk items are collated into a single list or action plan.

Risk Manager/Owner



Risk Monitoring and Control

Task Participants

Describe the methods and metrics for tracking the project’s risk status over time, and the way risk status will be reported to management.

Risk Manager/Owner

Each individual who is responsible for executing a risk mitigation plan carries out the mitigation activities.

Assigned Individual

The status and effectiveness of each mitigation action is reported to the Risk Manager every two weeks.

Assigned Individual

The probability and impact for each risk item is reevaluated and modified if appropriate.

Risk Manager/Owner

If any new risk items have been identified, they are analyzed as were the items on the original Risk Summary and added to the Risk Summary.

Risk Manager/Owner

The Risk Summary is regenerated based on the updated probability and impact for each remaining risk.

Risk Manager/Owner

Any risk factors for which mitigation actions are not being effectively carried out, or whose risk exposure is rising, may be escalated to an appropriate level of management for visibility and action.

Risk Manager/Owner

Project Quality Control Plan The plan combines the mandatory BCR covering all the project domains at some key milestones and the permanent quality control which will be synchronized with the Delivery Project Boards. The significant MOSIC BCR during the project execution are: BCR 2 at the end of the initiation phase BCR 3 at the end of the Solution building which can be divided on BCR 3.A for the Solution design and BCR 3.B for the Solution customization BCR 4 at the end of the Solution implementation BCR 5 at the end of the pilot and on preparation of the roll out phase BCR 6 at the end of the project acceptance for preparing the guarantee / maintenance phase For the ITMAS project, the following reviews are planned

Project Milestone

Lot Review level

Expected Achievements and quality controls to be applied

Quality control outputs

Project Kick Off

001A BCR2 Existing Project management plans ( PQP validated); Management committees; Staffing (both parties); Project office;

Review report with action list; Risk Portofolio and action plan;

End of Scoping

0x0 BCR3.A Scoping and specification accepted documents; Technical review on the detailed scoping ;

Technical review report; Risk findings and action plan;

Customization Plan

1x0 BCR3.B Detailed specification for the main application domains (group 1, 2 or 3); implementation plan Resources plan For Group 1: end of design activity for lots 110,120,180;




For Group 2: end of design activity for lots 130; For Group 3: end of design activity of Lots 150, 160,170

Delivery review

1x0 BCR3.C Delivery readiness review of all the modules for a domain (group 1 , 2 or 3) associated documentation; Internal tests results; For Group 1: delivery of customized modules for lots 110,120,180; For Group 2: delivery of customized modules for lots 130; For Group 3: delivery of customized modules for Lots 150, 160,170;


Solution implementation

1x0, 400

BCR4.A Integration plan including the localization plan and the data migration; Acceptance test plan; Documentation and train the trainers training reports;

Project review report; Risk findings and action plan;

Solution implementation

410,

BCR4.B Functional and global test reports; Change request plan and Quality indicators; Production environment for pilot readiness report; End user training plan;

Project review report Action plan ; Risk findings and action plan;

Pilot phase 510A, 520A

BCR5.A Help Desk readiness report; Pilot tests report; Data migration reports; End user training reports;

Project review report Action plan; Risk findings and action plan;

Pilot acceptance and Roll out launching

530, 540

BCR5.B Pilot operation reports (anomaly report); Change request reports; End user training reports; Data migration reports;

Project review report Action plan; Risk findings and action plan;

Roll out acceptance and maintenance / guarantee phase launching

550 BCR6 Roll operation reports (anomaly report); Change request reports; Contract for guarantee phase; Help Desk and level 1 support team staffing;

Project review report Action plan;

In addition to the former reviews, project reviews will take place in Cairo before each Delivery Project Board

Project Milestone

Review level

Expected Achievements and quality controls to be applied

Quality control outputs

DPB DPB preparation

Project reviews on the following items: Project progress and achievements Staffing and resource allocation plan BCR technical review findings and action plan Quality indicators prepared by the PMO Risk portofolio analysis and action plan Consortium meeting for resource allocation and pending issues Issues related to the Contractor’s planned tasks

Review report with action list. Risk Portofolio and action plan

The BCR or the DPB preparation review can recommend to launch a specific audit on a technical matter or on a project management procedure.

.



Quality assurance management

Delivery management Software delivery management The Bull Tax application software that will be delivered to the Contractor, is the resulting effort of the following processes business requirement analysis, design, customization, localization and integration processes.

Bull Tax and Customs competence center has defined a standardized implementation method in order to allow every project manage its own life cycle while maintaining a core application module suite.

The following chart lists all the steps and detail the inputs and outputs.

Step definition Actors Tools and Methods Inputs Outputs

Business analysis

(how the system functions can be used)

SBA, BSA

ETA Functional team

Business processes analysis and modeling (BPM) –

Sybase Power Designor

Business diagrams Existing procedure documentation

BPR results

Existing e-ris functions

Business Models by domain – Area decomposition and Business Process diagrams-

Functional analysis

(describe how the system functions)

SBA, BA, BSA

Functional team

ETA Business Analysts

UML diagrams (use cases and data models)

Business rules prototyping

Business Models diagrams

Existing forms and reports and Data structures

Existing e-ris use cases diagrams

ITMAS Use case specification : activity diagrams Scenarios and Business rules Entity life cycle diagrams

Gap analysis

System analysis

(describe how system functions are implemented)

BSA, BA Developt Mgr

Object programming (Java J2EE std)

FlexForms Designer

FlexFlow Designer

Tax Rule engine

Tax audit engine

Existing e-ris forms, workflows and data models ETA Tax description

Identification of objects impacted by customization

System object specifications Configuration of Existing Forms and Workflows Tax rule generation

Customization specifications

Updated Form layout specification

Updated Form cinematic

Adapted workflow diagrams

Localization Updated forms (exceptional)



Data domain (describe data used by system functions)

Developt Mgr; e-ris internal DB experts

FlexFlow designer

UML object diagrams

Existing e-ris data models

Conceptual data model for business entities Conceptual data model for system parameters Physical data model

Data modeling tools (Sybase Power Designor)

Customization specifications

Modifications of e-ris existing data entities

Modification of business rule related to data

Localization Message and screen table update

The competence center has described a software implementation procedure in order to standardize the configuration and the customization processes.

Following the procedures will guarantee that the e-ris version update can be mastered.

The localization process is well defined and the system is delivered ready for allowing changes into all the form’s fields and on the messages.

The software generation process is described into the system administration guide.

In order to simplify the system updates, it can be decided to generate a build per module. This build will include the data models owned by the module.

During the functional analysis, the functional test cases can be specified and validated by the functional workshop actors.

Non regression system and functional tests can be applied after each module update.

System environments

Project deliverables require to be implemented and tested into specific technical environments.

In addition the integration and training activities require also some specific environments.

On multi tier based Web based architecture, a technical environment includes the following standard software components

• Network access components (web server, intranet restricted access software) • Application server instances (potentially on clustered, load balanced configuration)



• Database server instance (potentially clustered, warm restart ready configuration)

The physical implementation of each environment is not the purpose of the present document.

During the course of the project, it will be defined the best suited configurations to host every required environment (consolidated, one to multiple environments per server, or distributed , one environment over several physical servers).

The following chart described the environment required for all the project phases.

Environment Purpose - Application Implementation responsible

Operation responsible Delivery and development environment

e-ris modules delivery - for system parameter or for localization

Environment used by Subcontractor for all module updates and correction delivery

Subcontractor technical expert

Subcontractor System Engineer

Integration environment Environment used for complete system integration (all prototyping tests), interface testing, data migration tests. Integration of correction before delivery for production.

Strictly Identical SW version and configuration than the production environment


Subcontractor System Engineer and DB administrator

Acceptance test environment Environment used by the Contractor’s testers in order to validate the delivery for each prototype (1, 2 and 3 levels) and pilots (phase 1, Phase 2 and 3)


Contractor Project Support team System Engineer and DB administrator

Training environment Environment used for the technical and IT training and then for the end user training


Contractor Project Support team System Engineer and DB administrator

Pre production environment Environment used for complete testing (system and functional) before pilot commissioning; need to host an exact copy of the production DB


Contractor Project Support team Operation Team

Production environment Environment used for production – will support the pilots (LTC, MTC) and the Roll Out sites

Potentially can be linked with a back up disaster recovery environment (need a warm restart DB)

Contractor administrators

Contractor Project Support team Operation Team



Documentation management

A project is a collaborative process between both parties, in which the Contractor’s teams are involved from the beginning till the project closure.

Documentation is the main support for this collaboration and is part of the project communication process.

The quality procedure linked to the project documentation needs to be strictly applied by all Project’s participant.

Documentation covers the following items: project correspondence, meetings reports, technical reports, specification documents, training documents, reference and end user guides.

The documentation quality procedure covers:

• the identification rule of all the documents, • the distribution lists and security rules associated to the document publication and

usage • the document life cycle • the document archiving

The present chapter summarizes the quality procedure for the ITMAS project documentation.

A documentation management plan details the various document templates, the security levels, the distribution rules, and the life cycle for each kind of document.

Structure and identification:

The general structure of a document is the following: • cover page • document history page • table of content • sections

The cover page contains the name of the originator, the project name, the document name

The document history page describes the revisions to the document.

The document reference to be provided in the page header must take a form respecting the documentation identification rule.



The following structure is proposed by ETA:

5 characters for department name, should be ‘ITMAS’

separator (example -)

type of document acronym (3 or 4 characters)

The most common are as follows: • PRJ Project Management documents;

• PQP Project Quality Plan;

• DFS Detailed Functional Specifications;

• DTS Detailed Technical Specifications;

• FTS Functional Test Specifications;

• FTC Functional Test Cases;

• SIR System Incident Report

• ATP Acceptance Test Process

• ACR Acceptance Certificate

13 Characters – can replicate the file name

Issue number or serial number

Year / Month

A - Arabic or E- English or AE - Arabic and English

E-Mail usage Rules

The email is a common vehicle to accelerate the distribution of the documents and of the project correspondence.



The email cannot substitute to formal project correspondence, which need to be attached to the message body.

The title of the email should indicate clearly the name of the correspondence or the document attached and the date of the exchange.

All the emails should be sent with the option – delivery notice required.

The other emails exchanged between project members for information purposes (appointments, meeting rooms,..) are informal and will not be covered by the project quality assurance.



Configuration management The role of configuration management is to manage the set of all items (documents, objects, software, hardware) that will compose the final product. Identification of the configuration items is the first activity of configuration management. It consists in giving a unique identification to each item (including documentation), which allows for distinguishing the different versions. The control of the contents of items is the second activity of configuration management. It includes configuration control and version control. Configuration management is a management process for establishing and maintaining consistency of a product’s functional and physical components with its requirements, design and operational information throughout the life of a project.

Configuration management includes the concepts listed bellow.

• Items subject to configuration management—Items that are directly involved with the system and are therefore part of system baselines. All aspects of configuration management apply to these items. These comprise:

• Repositories— One or more repositories, with appropriate access controls and procedures for backup and recovery.

• Version and build control—Version control provides unique identification of each version of a configuration item and the ability to recreate any version, and should support incremental progressions. Build control ensures valid combinations of components and versions, from subassemblies to the entire system, as well as the ability to recreate any build.

• Baselines—point-in-time collections, of specific versions of items, which become the reference points for subsequent change management. A baseline (for the applicable configuration items) represents a formal agreement between the Contractor and Bull.

• Change management — controls that the system does not diverge from its baselines without authorization and that the system includes all authorized changes.

• Status reporting — Information that is collected includes the physical characteristics of items, types and frequencies of changes and change status.

• Configuration audits—Periodic verification that configuration management is working correctly.

Typically, the Project Manager defines the major identification rules and the security attached to every kind of item. A technical expert will be assigned for setting up the configuration manager tools and initialize the access rights for all the project participants. He will also describe how to prepare a new build from the software objects stored into the configuration repository and how to deploy it on the target system. The TPM is in charge to supervise the configuration management activities; he will produce the status reports The Quality Manager will audit the configuration process as part of its periodical project review. The agreed Configuration Management Plan is a document that defines:

• The identification rule of any component.



• Procedures to readily determine the current version of any component from which the System is built, including its documentation and test status;

• Procedures to determine the versions of the configuration used within any baseline; • Methods and authorities to identify the reasons for any change to any component; • Tests Procedure to recognise other affected components if one component has to be

changed.

Validation and acceptance management

The Test and Acceptance strategy for the Project is based upon a series of tests or validations that will allow controlling the quality of the deliverables. Each deliverable is to be tested or validated and accepted.

The deliverables for this Project can be categorized as follows:

• Application System Software;

• Documentation;

• Training;

• Services (Installation, Adaptations, Integration, Planning, Support, Specifications);

The Subcontractor plans to apply the IEEE Std 829-1998, Standard for Software Test Documentation, as detailed in the Test and Acceptance Plan

The Contractor should assign a test and acceptance team for each domain (module or group of modules).

This team will cover:

The domain documentation validation The associated training documentation and curses The delivered software

Before starting the test and acceptance process, the team will define its test strategy, and produce test cases specification.

As part of the Test Specifications, the Criteria for acceptance for every Acceptance Test will be proposed by the Subcontractor and agreed with the Contractor. Such criteria should be agreed at least 3 weeks before scheduled start date of the related Acceptance Test.

An Acceptance Test is considered to be successfully completed and therefore the corresponding deliverable accepted by the Contractor, when the related acceptance criteria are met. Acceptance criteria will describe the number of permitted opened, i.e. uncorrected, anomalies by priority (from zero to X > 0) and rules for allocating anomalies to specific priority.

Categorization of incident and prioritization of fault / anomalies are common with the fault management procedure and independent of the domain.



The Subcontractor will confirm the team assigned to follow the domain acceptance.

All the test activities will be supervised by the Subcontractor TPM.

When several domains are being tested simultaneously in order to get a prototype operational or a pilot accepted, the Subcontractor will ask the POC to set-up an acceptance committee.

This committee will gather the Contractor testing team leaders, the Subcontractor application support engineers and the technical experts through the coordination of the TPM.

All the testing activities will be scheduled, in order the Subcontractor provide or agree upon the associated testing software environment and the test criteria.

The acceptance committee will review all the pending faults (anomalies) and approve the bug fixing (version replacement) strategy for each domain in order to pursue the acceptance process in a consistent way.

The Test and Acceptance Plan describes the scope and approach for tests that are required to be executed during the test phases by the Subcontractor and the Contractor project teams and the acceptance procedures which must be followed.

The Test and Acceptance Plan have been structured in the following parts:

• The first one provides the definitions and descriptions of acceptances and tests; presents the reference table between lots and acceptances;

• The second one describes test procedures, acceptance test documentation and the acceptance criteria.



Incident (issues ) management Incident assignment principles The incident or anomalies reported by the users or the project testers during the acceptance phase will be tracked through the tools put in place by the TPM and the technical team. The Project stakeholders will access those tools and be aware of the different stages of the calls and their resolution. The Subcontractor TPM will be responsible of the Incident Management status report. This report will be presented and explained at each Project Operational Committee. A quality indicator will be associated to the following criteria:

• Number of anomaly opened (registered) and not solved • Number of pending (non solved nor explained) blocking or critical anomalies

All the incidents or issues not documented through the tool (bugzilla) will not be registered as such and will not be analyzed by the Subcontractor. All the incidents or issues registered will be analyzed, reproduced and their status reported into the incident management registry. The Subcontractor will assign the application support team or the helpdesk team to reproduce any issues or incident being reported by the ETA application testers or the ETA end users. All anomalies will be categorized into one of the following levels: blocking, critical, major, normal or minor. Blocking and critical anomalies are directly routed forward the Subcontractor technical experts and the application support team in order to find a workaround as rapidly as possible. Other issues are processed first by the help desk team or the application support team in order to locate the potential origin and try to identify if the e-ris application have been used with the right parameters or if some database errors can justify the issue. If the incident is a bug (i.e. anomaly) and is not resolved at the level of the Help desk or the application support team and related to the Bull Tax Application deliverables in the Project, it is entered by the application support team into the database as a System Incident Report (SIR). The entry should be made in English in the relevant database for processing by the development team of the Bull Software Engineering Center (SEC), any supporting document or files (screen shots, DB dump, error logs, sequence details to reproduce the problem) should also be attached to the report. All elements allowing the support team to reproduce the anomaly must be provided, otherwise the anomaly declaration can be rejected and the SIR will be closed (with Can Not be Reproduced or CBR raison code). If the issue is related to a functional discrepancy between what the end user is expecting and what the specification documentation describes; the issue can be identified as a Change Request at that stage and then tracked as such with the Change Control Board procedure after being validated and confirmed by the ETA’s Project Manager as a relevant Change Request (CR). The related issue is then closed. This might happen in particular when the implementation conforms to the specifications and a change of specification is desired at that stage. If the issue is an anomaly, i.e. bug, which is not due to the e-ris application, it is forwarded to the ETA IT support group having in charge the interface with the horizontal software suppliers (Microsoft Windows and SQL Server, application server supplier..).



The Bull SEC receives System Incident Reports (SIR). The process for reporting errors to the Bull Software Engineering Center follows a workflow as indicated on the next page.

Escalation process The list of the currently open incident will be reviewed every day by the Helpdesk team leader or the TPM (during the acceptance phase) and will be tracked as a weekly report. The issues being reported as System Incident Reports (SIR) to Bull SEC are generally related to:

• Functional non conformances • Incidents met during production or pre-production testing for fixes delivered

Each SIR has a specific priority and severity in the SEC database and is processed accordingly. The severity for anomaly is set according to the criteria below:

Change Request

Evaluate:

1) CR Cost 2) Time to implement 3) Implications on system

specifications 4) Implication on schedule.

Decision to implement?

Update system specifications, delivery schedule, and other

documents accordingly.

End

SIR

Categorize and assign priority

New requirement

Not reproducible,

Normal behavior,

Invalid data

Type of incident

Update SIR

Bug anomaly

SIR Analysis

Develop fix

Deliver fix

Test OK?

Non-regression tests OK?

No Yes

Yes

Yes No

No

Close SIR

Update CR

Legend:

Document produced

Project



Blocker (Severity level 1A): An anomaly is considered blocking when it prevents the end-user from operating the e-ris Application Software. Examples of such blocking anomaly include data base corruption, which cannot be fixed without system reloads, requiring manual data entry, inaccessibility, or errors causing system reloads. Usage of the e-ris application cannot continue when there is a blocking error. Critical (Severity Level 1B): An anomaly is considered critical when a transaction/operation can not be completed or it causes wrong calculations/results while using correct input data, and when there is no acceptable workaround for the Application that is available to the end-user. An “Acceptable workaround” means a workaround provided by the Subcontractor and that will permit the end-user to perform its obligations within reasonable delays. Major (Severity Level 2): An anomaly is considered major when a transaction/operation can not be completed or it causes wrong calculations/results while using correct input data, or it has other business impact, and when there is an acceptable workaround for the system which is available to the end-user. Normal (Severity Level 3): An anomaly is considered Normal when a transaction/operation that can not be completed has an insignificant business impact or when there is an acceptable workaround for the system that can be used and that permit the end-user to perform its obligation without delays. Minor (Severity Level 4): This type of anomaly does not have a business impact and refers to error in reference manuals. It also refers to cosmetic or syntax problems or to technical errors not impacting the business operations, including screen or report layout and/or text/spelling errors. The Priorities range from P1 (highest) to P4 (lowest): the priority is set by the application support team or the Help desk team leader to indicate to the Bull SEC the order in which it would like to receive fixes to SIRs. The processes and response times from the Bull SEC are consistent with a timely resolution of the defects (non conformance with the specifications) and anomalies (bugs) being notified by ETA:

• Severity Level 1: 1 day; • Severity Level 2: 2 days; • Severity Level 3 and Level 4: next release

In order to escalate a SIR, its priority and severity can be changed by the Help Desk team leader after the SIR has been sent to Bull SEC. As a recommended practice and during the pilot implementation and roll out phases, a weekly incident management meeting should be organized between the TPM , the Helpdesk Team Leader, and the Development Manager in the Bull SEC in order to review the SIR being in process at the Bull SEC, exchange information and anticipate on deliveries of fixes.

Resources and resolution process The status of the SIR follows a standard process as explained on the chart hereafter



As soon as a new SIR is entered into the system (“new”), an initial review is conducted by the Team Leader of the Bull SEC in charge of the related e-ris module. The Team leader is the owner by default of the SIR. Each team is in charge of the development and support of an e-ris module. If the SIR is confirmed to be an Anomaly (i.e. bug), it is “assigned” to a developer of the team once the alternatives for the fix have been determined and resolution choices made. The SIR is set as “resolved” when the fix has been produced and tested by the developer and checked the Team Leader. The fix is then sent for integration to the delivery manager of the Bull SEC. The SIR is tested in the integration system of the Bull SEC and then set as “verified” and allowed to be delivered to the Project. Once the delivery comprising the fix is received by the TPM , it is to be checked in the Project environment on site by the application support team and then it will be set as “closed” by its issuer. In case of negative test for the fix, the SIR will be set as “reopen” by the tester and owned by the Team Leader for resolution.



Change management

Changes may occur from various reasons in a project :

• Functional change requests • Correction requests • General project issues which are not covered by the previous categories • Etc ...

All these issues must be formally reported and tracked down to their resolution. A procedure must be set up to define the issue report format, the process and the responsibilities to raise, review, solve and close these issues. A Change Request Note (CRN) is used to describe the change request or to underline the issue that can be detected during the acceptance tests. It will be used to track all stakeholder requests (including new features, enhancement requests, defects, changed requirements, etc.) along with related status information throughout the project lifecycle. All change history will be maintained with the Change Request, including all state changes along with dates and reasons for the change. This information will be available for any repeat reviews and for final closing. The change requests will be listed in the POC and if many change requests are submitted, the POC will create a Change Control Committee or Board in charge to define priorities and analyze more precisely the functions impacted. The Change Control Board (CCB) is the committee that will examine all the Change request notes and will oversee the change process. The TPM will be the Subcontractor permanent member of the CCB and will be in charge to prepare the minutes. Depending on the change request nature, the POC can decide to add to the committee some members such as a Functional Integration Consultant, a Project team support member , the Subcontractor’s team leader. During a CCB Review Meeting, the submitted Change Requests Notes are reviewed. An initial analysis of the contents of the Change Request is done in the meeting to determine if it is a valid request and the potential area concerned – e-ris module parameter, e-ris module extension, tax rules, audit rules, Data base content. The analysis, once performed, will document the different impacts for the implementation of the CR: load, schedule, changes in documents, testing, and delivery. The Change Request form will be updated at each stage. If the CCB cannot make a decision upon the CR workload estimate , an escalation process is launched towards the POC. At this level, if no agreement is found about the CR impacts, on cost and schedule, an escalation to the Project Board will be decided. The TPM as permanent member of the CCB, will keep track of:

• the CRs portfolio; • the implementation and delivery schedules; • the consumption of workload attached to the activity; • the testing of deliveries and of the CRs in the user environment.

Additionally, the TPM will issue reports to the CCB and the POC on this activity.



The agreed Change Control Plan (see Change Control Plan document) describes more in detail, the change management process applied to all the components in the scope of supply: standard software, application software, customization specification, documentation.

The Change Control Plan covers: • Originators of changes and formats of request for change in the scope of supply or scope of

work; • Change evaluation phases; • Authority of change control and responsibility for actions to be taken; • Organisation of Change Control Board; • Effects of changes to the Project Plan.

For all major changes impacting the project’s scope and global schedule, the CCB will only report to the POC the workload estimates.

The POC will prepare a plan and submit it to the Delivery Project Board which is the first coordination committee able to study a contract amendment.



Implementation Plan This chapter covers the different ITMAS phases and describes for each phase the methods and the main outputs.

e-ris Solution Definition methodology

Bull Tax Application software suite for tax brings a set of modules that can be customized and integrated within existing customer applications (portal, accounting, HR)

The Solution definition activity has three main objectives: to clarify ETA's business activities and operations that are included in the scope of the project and achieve common understanding between ETA and the consortium teams on how these business operations will be supported by the customized e-ris Application software, to specify:

(a) which application operations will support the defined business requirements as per item (i),

(b) how system functions shall be set up (parameters used) or shall be adapted to provide system functionality as specified as per item (ii) required,

(c) which changes are required in ETA working procedures (this action is part of the BPR external project to be implemented by ETA).

to plan the further implementation tasks and acceptance testing of the Application System Software.

These objectives will be achieved through two steps technical implementation:

(i) Overall technical implementation for whole application package (first level technical implementation) including and called Business Area Definition and High Level Functional Technical Implementation.

(ii) Detail technical implementation for each functional area (second level technical implementation) called Functional Analysis. This second phase can be done in two iterations: core functions and then secondary functions.

Business Area Definition and High Level Functional specification The ETA business requirements (TO-BE state) to be automated within the project scope will be mapped to the Functional Areas listed above. As a result of this exercise the Application module to support each business requirements will be identified. If a given requirement will be supported by more than one module then this case will be considered in more details in order to put a clear boarder between these modules and define the proper flow between them.

The mapping will be performed as a series of working sessions between ETA and Bull teams addressing a given Functional Area with involvement of respective the ETA key users. The list of external interfaces and links to external systems will also be confirmed, and assigned to the related areas. Entities subject to data migration will also be identified.



In order to familiarize the ETA team with main application operations and capabilities, Bull will provide application functional overview training for participants involved in process of business area Definition. During this activity each requirement will be clarified and properly documented.

The outcome of this step, will be documented as a matrix with business requirements versus application modules.

In cases where business processes are uncovered by the application modules or it is not clear what application module to be assigned, the further considerations will be done in order to clearly specify what module will be assigned to support these processes.

Business requirements are also clarified by Functional Area and a compiled Functional Requirement document is prepared. Bull will prepare these documents and will submit them to the Contractor for approval.

Based on results of this Overall specification, the planning for application system implementation will be updated and acceptance test specification will be defined. The working groups will be assigned to Detailed Specification and Technical Implementation activity (per Functional Area).

Detailed Specification and Technical Implementation Functional analysis (second level specification and implementation) will be performed for each Functional Area in order to:

(i) Define how the application operations shall be set-up and/or adapted in order to support this business requirements, and

(ii) The Contractor (ETA- BP) will analyze how the end-user working procedure shall be adapted or changed in order to operate using the new application system. Such changes will be documented by the Contractor as part of its internal BPR process (the BPR process is outside the scope of this Project)

(iii) The new functions, that are within the contractual scope and that are not covered by the existing modules or the functions to be adapted will be described precisely

The detailed specification and technical implementation will be performed as a series of working sessions between the Contractor and Bull teams addressing a given business processes with involvement of respective ETA key users and consultants. In order to facilitate this process and deeper familiarize the ETA team with application operations and capabilities, Bull will provide application module training for the participants.

The outcome of this exercise will be documented in: (i) Parameters guide that describes how the operation shall be set-up (system parameters

used) to support the respective operations in accordance with business processes details (ii) Technical specifications for the adaptations to e-ris application in order to support the

required functionalities.



(iii) Data Migration and External Interface Strategy will describe the standard interfaces that are provided to support links to external systems and data migration from legacy systems, concluding control reports. The data migration process will also be specified.

These documents will be produced by Bull team and submitted to the Contractor for approval.

In accordance with these documents, Bull will perform the module integration and the Contractor will implement the required changes in users working procedures in order to operate business operations using the new application system.

Based on results of the Detailed Specification and Technical Implementation, the planning for further steps in application module integration will be updated and detailed contents for acceptance test specification will be defined. The expected outputs for the scoping phase are:

• To provide the user with a complete functional model of the recommended system Solution in line with the Contractor’s demand.

• To provide technical designers with a detailed functional specification on which to base the technical design of the system.

• To confirm implications on testing, documentation, implementation, organization and training.

• To confirm system configuration requirements.

The scoping duration is 5 (five) calendar months

Bull Tax Application Solution Pilot Development and Implementation

This Phase covers the building of the tax application including the analysis, the detailed technical implementation, the adaptation/localization, the integration and the acceptance testing of the Application System Software.

The Pilot Implementation will be performed in 2 (two) main steps: a. Delivery of adapted/localized e-ris-3 modules, including interfaces to external systems and scipts for data migration, to be integrated into a Prototype;

b. Preparation and installation of the tax application, including data migration from legacy systems on two sites for a trial run, LTC and MTC pilots.

Building the Application System Software

The project team will undertake detailed specifications for the e-ris-3 set-up and adaptations. This is performed Functional area by Functional area: • Area 1 (Lot 110): Control Area;



• Area 2 (Lot 110): Registration Area; • Area 3 (Lot 110): Assessments Area; • Area 4 (Lot 110): Revenue accounting Area; • Area 5 (Lot 110): Enforcement Area; • Area 6 (Lot 110): Taxpayer Audit Area; • Area 7 (Lot 110): MIS Area; • Area 8 (Lot 110): File & Document Control Area

The Subcontractor team will then develop the adaptation of each of e-ris module. Once these customizations have been completed, they will be delivered to the integration environment at the Project Office for set-up and testing. These adapted products will be delivered with related release notes (i.e. code versions, functionality, test scripts and test results, performance statistics, deployment procedures, etc.)

During the integration phase on site, major work-packages will be performed during this phase: • Providing advance training to the Project Team; • Establishing the system management strategy and configuring the technical infrastructure; • Performing localization for Arabic; • Setting-up parameters according to the contractor needs; • Configuring and testing an initial prototype (baseline) for major functions and processes; • Validating conversion, interface and data transfer programs; • Configuring and verifying the final adapted e-ris system, this is based on an iterative

approach to the prototypes; • Creating reports; • Planning and technical implementation of archiving strategy; • Data migration to load a test database and to validate the migration process; • Validation of interface stubs or test links for external systems; • Performing a final integration test • Preparing end-user documentation and training material.

Once the prototype is completed, Pilot at LTC and MTC sites will start In Pilot phase the following activities will be performed:

• End-user training (Subcontractor); • Connection to external systems; • Initial Data Loads and Cut over (Contractor’s team); • ETA ITMAS Help Desk set up (Contractor’s team) with the Subcontractor’s support • Anomaly removal for those anomalies that are left from previous steps, and those that are

discovered during Pilot (by Subcontractor). The overall duration for this Solution building and Pilot delivery phase is about 13 months, starting at the completion of the Scoping and Planning Phase (Phase 0). During the Pilot, the software application will be validated by a “Parallel Run”, i.e. a Trial Run, with “real users” and live data.

Activities assigned to ETA Project development team During the prototyping and pilot integration phases, the ETA Development team and Support team will follow the technical training program and will be associated to the Subcontractor’s integration activities.



The activities assigned to the ETA groups, will help the trained engineers mastering the software application development, and the system building concepts. The development engineers can be associated to the localization process and to the definition and adaptations required to interconnect the ITMAS system with external bodies. Bull localization engineers will use the internationalization features embedded into e-ris in order to provide an initial localized system. This level can be improved with the help of the ETA development team. Bull will publish all the standard interface structure (XML expected structure) for each module (registration, revenue accounting ..) and the object module in charge to process with the external data. These specification and object classes can be used to import data during the migration phase or to exchange data with external bodies. The technical analysis of the external interfaces and the potential alignment with the expected message structures can be performed by the ETA development team with some advices and support from Bull technical experts. e-ris MIS module will provide ETA with a set of standard reports. Additional reports can be specified as part of the change request policy and developed by Bull. They can also be developed by the ETA project team if they become familiar with Crystal Report utility and the e-ris data structures. For all the activities assigned to ETA personnel, the following rules will apply:

• The Subcontractor will train the ETA as planned on the contract (lot 400) and will support the team during their first move towards e-ris technology environment (data exchange structures, report building).

• ETA will manage the resources, and will apply the corresponding quality control procedure (schedule, quality indicators)

• Any development made by ETA will remain under ETA responsibility and the ETA will not include the issues related to their own software production with the Subcontractor’s deliveries.

Roll out Phase

At the end of pilot phase – one month after pilot commissioning- the deployment of the Solution will be done on ten sites : 5 additional MTCs and 5 STCs.

All these sites should run the same application software than the pilots, without any change into the working parameters except, the end user directory, the center location, the names of the officers in the standard letters.

The main activities to be performed for the roll out are:

• End –user training (Subcontractor) • Data loads for each site (Contractor’s team with Subcontractor’s support) • Update of the end user directory and rights (Contractor’s administrator with

Subcontractor’s support) • Update of the standard letters (Contractor’s IT people with Subcontractor’s

support) • Technical (connection) and functional testing (Contractor’s team)



Implementation tools

Domain Details TOOLS

Software Methodology and Development

Bull Internal methodology and development guidelines for IT projects.

BULL MOSIC™ tools for planning, specification, integration, tests

PMbook(PMI).

Conceptual Design and Functional Design

U.M.L. Unified modelling language

Tool used during the analysis and design phase (manage Use Cases, manage UML designs

Sybase Power Designer

e-ris customisation Changes applied to screens, workflow, tax rules engines and Audit Rule engine

Bull FlexStudio

Tax Rules Maintenance

Audit Rules Maintenance

Configuration management (repository)

Global Object (code, documents, tests..) version management ; change impact analysis

CVS

Project planning and tracking

Task scheduling , GANTT

Critical path analysis

Microsoft Project

Load / Performance Testing

Testing tool used for test management and "automatic" testing

OpenSTA



Appendix

APPENDIX A: Project Committees members lists

Steering Committee permanent members

ITMAS Steering Committee Members

Contractor Serial Members Designation

1 Dr. Ashraf Al Arabi Deputy Minister for Tax Policy and Tax Commissioner

2 Dr. Ahab Eyada Assistant Minister for IT

3 Mr. Gamil Ezzat Advisor to the Minister; IT & Tax Integration PM

4 Mr. Terence Murdoch Managing Director, Bearingpoint Egypt.

5 Mr. Fathy Abd Azez Head of Information Sector

6 Mr. Said Hindawi Head of LTC Sector

7 Mrs. Essmat Ali Hassan Head of MTCs Sector

8 Mr. Mohamed M. Azmy Head of STCs Sector

9 Mr. Fatos Qendro Technical Advisor and Contract Manager

10 Mr. Tarek Orphy Advisor IT and Projects Manager – IT Program Director

11 Mr. Ziad M. Rotaba Project Manager

Subcontractor

Serial Raya Members Designation 1 Ahmed AbdelSattar Chief Operations Officer

email: [email protected]

2 Mohamed Badra Project Management Manager – Government sector,


3 Hesham Ghallab Project Management General Manager


4 TBA Contract Manager

BULL SAS Members

5 Yassine Fergani Bull Middle East GM

[email protected]

6 Fares Louis Bull Middle East GM

[email protected]

7 Jean François Betbeder Bull Business Applications VP

[email protected]

8 Michel Bahurlet Bull PM

[email protected], [email protected]

mailto:[email protected]







Delivery Project Board committee members

ITMAS Project Board Members

Contractor

Serial Members Designation 1 Mr. Fathy Abd Azez Head of Information Sector

2 Mr. Mohamed Omara Head of IT Central Departmet, Sales Tax

3 Mr. Fatos Qendro Technical Advisor and Contract Manager

4 Mr. Eissa Al Wakeel Head of Survey Central Department.

5 Mr. Mohamed Hassan General Manager, LTC Computer Centre.

6 Eng. Ali Khafagi Advisor, Infrastructure

7 Eng. Ziad Rotaba Project Manager

8 Mr. Tarek Orphy Advisor IT and Projects Manager - IT Program Director

Funcional Integration Group

1 Mr. Yehia Mitwali Head Of Legal Afairs Sector

2 Mr. Mohamed Mohei Head of Tax Operation Sector - Sales Tax

3 Mrs. Faten Ismail Head of Tax Operation Sector – Income Tax

4 Mrs. Hamdy El Esawi Head of Audit Central Department

5 Mrs. Fatma Baiomi General Manager – Collection LTC

6 Mr. Fathy Shaban General Manager – Audit Central Department

7 Mr. Mohamed Fergani General Manager – Tax Operation Sector

Subcontractor

Serial Members Designation 1 Mohamed Badra Project Management Manager – Government sector,

2 Hesham Ghallab Project Management General Manager

3 TBA Contract Manager

4 Fares Louis Bull Middle East GM

5 Jean François Betbeder Bull Business Applications VP

6 Michel Bahurlet Bull PM



Project Operation Committee members

ITMAS Project Operation Committee

Contractor

Serial Permanent Members Designation/Business Areas 1 Mr. Fatos Qendro Technical Advisor and Contract Manager

2 Mr. Tarek Orphy Advisor IT and Projects Manager - IT Program Director

3 Eng. Ziad Rotaba Project Manager

4 Mr. Hamed Sadeq Assistant Project Manager

5 Mr. Khaled saad Head of Analysis Team

6 Mr. Abdel Tawab A. Azim Head of support Team

7 Mr. A. A. Maqsoud Head of Programming Team

Functional Consultancy Group

8 Mr. Mohamed fergani Registration, Return & Document Processing, Paymant

9 Mr. Fathy Shaban Audit selection, Audit Management

10 Mrs. Maha Sharawi Enforced Collection

11 Mr. Magdi Saleh Tax Payer Services

12 Mrs. Etimad Qedis Appeals and Objection

13 Mrs. Elham Azmy Management Information System

14 Mrs. Fatma Awad Management Information System

15 Mr. Ahmed Youssef External Interfaces and Work Flow

16 Mr. Gamal Abdel Khaliq External Interfaces and Work Flow



ITMAS Project Operation Committee

Contractor

Serial Permanent Members Designation/Business Areas Team Members

1 Mrs. Safa Abdel Monaim Registration, Return & Document Processing

2 Mrs. Samia Orabi Registration, Return & Document Processing

3 Mrs. Rafat Najm Riadh Registration, Return & Document Processing

4 Mrs. Misak Aiad Registration, Return & Document Processing

5 Mrs.Nagwa Taher Registration, Return & Document Processing

6 Mr. Kamel Metimid Document Processing

7 Ayman Ahmed Mohamed Document Processing

8 Mrs. Maha Sharawi Payment Processing

9 Mrs. Zakia Fathy Tax Payer and Revenue Accounting

10 Mr. Nabil Noshy Kerolos Stop Filers & Delinquent Taxpayers

11 Mr. Kasem El Sherif Audit Sellection

12 Mr. Ahmed Gamal Audit Sellection & Audit Management

13 Mr. Mohamed Ramdan Audit Management

14 Mr. Mohamed Abdel Baki Audit Sellection & Audit Management

15 Mr. Abdel Hadi Ismail Enforced Collection

16 Mr. Abdel Fatah M. Ahmed Enforced Collection

17 Mr. Khaled Goma Enforced Collection

18 Mr. Mahmoud Shams Taxpayer Services

19 Mr. Mohamed Atia Elhosary Taxpayer Services

20 Mr. Sabry Abdel Monaim Taxpayer Services

21 Mrs. Mona Nagati Taxpayer Services (Tax Refund)

22 Mr. Farag Abdel Samiaa Taxpayer Services (Tax Refund)

23 Mrs. Thoria Goma Appeals and Objection

24 Mrs. Samia El Mola Appeals and Objection

25 Mr. Abdel Gawad Kamal Appeals and Objection

26 Mr. Ali Lotfy Appeals and Objection

27 Mrs. Safinaz Morsi Management Information System

28 Mr. Essam Salah Eldin Management Information System

29 Mrs. Susan Abdel Haq Management Information System

30 Mrs. Gamalat El Sayed Management Information System

31 Mrs. Raga El Bargouth Management Information System



Subcontractor

TBA Contract Manager

Michel Bahurlet Bull PM

Bull TPM

Committees report distribution lists :

The Contractor’s Project Manager will forward the agreed reports and minutes to the people on the distribution list of the Contractor. And the Subcontractor’s will do the same for the people on the distribution list of the Subcontractor.

. Name POC DPB DSC Contractor Name Title Email address Dr. Ashraf Al Arabi √ Deputy Minister for Tax Policy and Tax

Commissioner

Dr. Ahab Eyada √ Assistant Minister for IT Mr. Gamil Ezzat √ Advisor to the Minister; IT & Tax Integration

PM

Mr. Terence Murdoch √ General Manager, Bearingpoint Mr. Fathy Abd Azez √ Head of Information Sector Mr. Fatos Qendro √ √ √ Technical Advisor and Contract Manager Mr. Tarek Orphy √ √ √ Advisor IT, IT Program Director Mr. Ziad M. Rotaba √ √ √ Projects Manager Mr. Said Hindawi √ Head of LTC Mrs. Essmat Ali Hassan √ Head of MTCs Sector Mr. Mohamed M. Azmy √ Head of STCs Sector Mrs. Mohamed Omara √ Head of IT Central Department, Sales Tax Mr. Eissa Al Wakeel √ Head of Programming and Development

Department IT (Income Tax).

Mr. Mohamed Hassan General Manager, LTC Computer Centre. Eng. Ali Khafagi √ Advisor, Infrastructure Mr. Yehia Mitwali √ Head Of Legal Afairs Sector Mr. Mohamed Mohei √ Head of Tax Operation Sector - Sales Tax Mrs. Faten Ismail √ Head of Tax Operation Sector – Income Tax Mr. Hamdy El Esawi √ Head of Audit Central Department Mrs. Fatma Baiomi √ General Manager – Collection LTC Mr. Fathy Shaban √ General Manager – Audit Central Department Mr. Mohamed Fergani √ General Manager – Tax Operation Sector Mr. Hamed Sadeq √ Assistant Project Manager Mr. Khaled saad √ Head of Analysis Team Mr. Abdel Tawab A. Azim √ Head of support Team Mr. A. A. Maqsoud √ Head of Programming Team Mrs. Maha Sharawi √ Enforced Collection Mr. Magdi Saleh √ Tax Payer Services Mrs. Etimad Qedis √ Appeals and Objection Mrs. Elham Azmy √ Management Information System Mrs. Fatma Awad √ Management Information System Mr. Ahmed Youssef √ External Interfaces and Work Flow Mr. Gamal Abdel Khaliq √ External Interfaces and Work Flow



Name POC DPB DSC Contractor

Name Business Area Email address

Mrs. Safa Abdel Monaim √ Registration, Return & Document

Processing

Mrs. Samia Orabi √ Registration, Return & Document

Processing

Mrs. Rafat Najm Riadh √ Registration, Return & Document

Processing

Mrs. Misak Aiad √ Registration, Return & Document

Processing

Mrs.Nagwa Taher √ Registration, Return & Document

Processing

Mr. Kamel Metimid √ Document Processing Ayman Ahmed Mohamed √ Document Processing Mrs. Maha Sharawi √ Payment Processing Mrs. Zakia Fathy √ Tax Payer and Revenue Accounting Mr. Nabil Noshy Kerolos √ Stop Filers & Delinquent Taxpayers Mr. Kasem El Sherif √ Audit Selection Mr. Ahmed Gamal √ Audit Selection & Audit Management Mr. Mohamed Ramdan √ Audit Management Mr. Mohamed Abdel Baki √ Audit Selection & Audit Management Mr. Abdel Hadi Ismail √ Enforced Collection Mr. Abdel Fatah M. Ahmed √ Enforced Collection Mr. Khaled Goma √ Enforced Collection Mr. Mahmoud Shams √ Taxpayer Services Mr. Mohamed Atia Elhosary

√ Taxpayer Services

Mr. Sabry Abdel Monaim √ Taxpayer Services Mrs. Mona Nagati √ Taxpayer Services (Tax Refund) Mr. Farag Abdel Samiaa √ Taxpayer Services (Tax Refund) Mrs. Thoria Goma √ Appeals and Objection Mrs. Samia El Mola √ Appeals and Objection Mr. Abdel Gawad Kamal √ Appeals and Objection Mr. Ali Lotfy √ Appeals and Objection Mrs. Safinaz Morsi √ Management Information System Mr. Essam Salah Eldin √ Management Information System Mrs. Susan Abdel Haq √ Management Information System Mrs. Gamalat El Sayed √ Management Information System Mrs. Raga El Bargouth √ Management Information System

Subcontractor Name Title Email address Ahmed AbdelSattar √ Chief Operations Officer [email protected] Mohamed Badra √ √ Project Management Manager – Government

sector, [email protected]

Hesham Ghallab √ √ Project Management General Manager [email protected] TBA √ √ √ Contract Manager Michel Bahurlet √ √ √ Bull PM [email protected], Yassine Fergani √ Bull Middle East and Maghreb General Mgr [email protected] Fares Louis √ √ Bull Middle East GM [email protected] Jean François Betbeder √ √ Bull Business Applications VP [email protected] Guerson Essayag √ √ Bull QM [email protected]








APPENDIX B: FORMS TEMPLATES

Project follow up report

Projects Follow up Report

From To Page: …./….

..../..../...... ..../..../......

Period:

Distribution List To : MM. Tarek Orphy and Fatos Qendro

Copy to :

Project

Michel Bahurlet

PM & Ass.: ITMAS Name & Ref:

Activities Summary

Activities Completed During the Period Covered in The Report



Problems, Major Issues, and Risks

Activities Expected to Finish During the Period between This Report and The Next Report

Prepared By:

Date:

Enclosures:

Signature:

Form Ref: 03 ـ 01



Milestones follow up report

Page: …./….

Planned Amended Actual Planned Amended Actual

Planned Amended Actual Planned Amended Actual

Project Name:

S.

Mile Stones Follow Up report

Start Date: End Date:

End DateStart DateActivity

Form Reference: ………………

Project Number:

Version: Status: Preparation Date: Prepared By: Signature:



Acceptance form

Raya Acceptance Certificate or Delivery Notice Bearing Point Project: Integrated Tax Management Administration System (ITMAS)

Contract ref: AID -2007-C- 00063 – 01301

Description of Goods and or Services :

Supply of Application System Software and attendant Services for an Integrated Tax System

Dated: (tbc)

Type of Acceptance/Milestone: (to be filled)

Date: (yy/mm/dd) Ref.: (xxx)

: Reference Number and Designation of the milestone : :

xxxx/xxxx

xxxx/xxxx Product and Services accepted:

(to be listed)

Reserves:

(To be listed if any) or None

The Parties agree that the Supplier has delivered to the Purchaser the Products and Services in accordance to the Contract , including items mentioned in the Lot (to be completed) of the Contract

For and on behalf of BearingPoint For and on behalf of Raya

Authorized Representative :

Name :

Signature :

Authorized Representative :

Name :

Signature :

Seal : Seal :

Date : Date :

Bull Complementary Information:



Acceptance form For Lot Details

شهادة قبول أو اخطار توريد

Acceptance Certificate or Delivery Notice Project: Integrated Tax Management Administration System (ITMAS)

Contract ref: AID -2007-C- 00063 – 01301 Dated: 11 / 9 / 2007.

.النظام المتكامل لادارة وتشغيل الضريبة: أسم المشروع AID -2007-C- 00063 – 01301: لعقدرقم ا

.2007 / 9 / 11: بتاريخ

Initiated By: مقدمة بواسطة/الشهادة معدة :

Description of Goods and or Services subject of this certificate:

:المنتج و الخدمات التي تشملها الشهادة/ وصف البضاعة

Type of Acceptance:

Date:

Ref.:

:نوع القبول

: التاريخ

:المرجع

Reference Number and Designation of the project Lot related to the products/services subject of this certificate:

المرجع ومميز الجزء من المشروع المرتبط بالمنتجات أو :الخدمات موضوع هذه الشهادة

Reserves (If Any):

): إن وجدت(تحفظات

The Parties stated hereafter agree that the Subcontractor has delivered to the Contractor the Products and Services subject of this certificate in accordance to the Contract stated above in this certificate.

هم فيما بعد على قيام المتعاقد معه على أتفق الاطراف المشار اليتوريد المنتجات أو الخدمات موضوع هذه الشهادة الى المتعاقد

. طبقا لما جاء في العقد المشار اليه اعلاه في هذه الشهادة

Parties Involved in Acceptance الاطراف المشارآة في القيول

Name وتاريخ توقيع Signature & Date الاسم

Attachments:

: مرفقات



Contractor Authorised signature المخولون بالتوقيع من جانب المتعاقد

Name توقيع وتاريخ Signature & Date الاسم

Mr. Fatos Qendro

Contract Manager

فاتوس آندرو . أ

مدير العقد

Mr. Ziad M. Rotaba

Project Manager

ياد محمد رطبةز. م

مدير المشروع

Subcontract Authorised signature المخولون بالتوقيع من جانب المتعاقد معه

Name توقيع وتاريخ Signature & Date الاسم

Contract Manager

مدير العقد

Mr. Michel Bahurlet

Project Manager

باهرليت ميشيل. أ

مدير المشروع



Change request note template

The Change Request Note template is attached to the Change Control Plan.

Risk Record form

Date : Risk Record FORM

Project Name: ETA ITMAS Project Manager

Risk Identification Risk Name: Risk I/D#:

Identified By: Date: Risk Owner:

Risk Description: (What might happen/not happen/go wrong)

Risk Consequences: (What might be the adverse effects on the project)

Initial Risk Assessment: Probability Rating: H / M / L Impact Rating: H / M / L

Pre Mitigation Risk Evaluation

Time Impact: Cost Impact: $ or

Resource Impact

Probability: % Expected Risk Value ($ × %) = $

Notes:

Mitigation Strategy

Mitigation Cost: $ or resources

Post Mitigation Risk Evaluation

Mitigated Time Impact:

Mitigated Cost Impact $ Mitigated

Probability: % Mitigated Risk Value ($ × %) = $

Notes:



Mitigation Action Plan

Action By Whom By When


1

Technical Assistance for Policy Reform II BearingPoint, Inc,

18 El Sad El Aali Street, 18th Floor, Dokki, Giza

Egypt Country Code: 12311

Phone: +2 02 335 5507 Fax: +2 02 337 7684

Web address: www.usaideconomic.org.eg