ICT Introductory Documentmoct.gov.sy/ICTSandards/en_pdf/1.pdf · 2008. 5. 17. · The ICT Project...

Institutional and Sector Modernisation Facility

ICT Standards

Project Funded by the European Union

ICT Introductory Document Document number: ISMF-ICT/3.02 Version: 1.2

1 Document control

1.1 List of Abbreviations Abbreviation Description ICT Information and Communication Technology ISMF Institutional and Sector Modernisation Facility PLC Project Life Cycle

1.2 Purpose of this Document The purpose of this document is to provide the Syrian Public Sector staff with an overview to the PLC approach used to build a conceptual framework for the deployment of ICT Standards.

ICT Introductory Document Page 1 ISMF-ICT / ISMF - ICT Standards

2 Introduction The ICT Project Life Cycle (PLC) document describes the processes for conducting ICT projects and assignments in the Syrian Public Sector. The current document, � Outlines a typical ICT - Project Implementation Team, its organization and roles and

responsibilities associated with each project team member (Chapter 3). � Introduces the main phases of the PLC for the most common cases and describes a set of

guidelines for the implementation approach of each of the Phases (Chapter 4). � Provide a list of supporting deliverables and their links with the PLC documents.

2.1 Purpose and Audience The purpose of this document is to provide the Syrian Public Sector staff with an overview to the PLC approach used to build a conceptual framework for the deployment of ICT Standards. The audience consists of the Syrian Public Sector ICT specialists (either technical staff or project managers, business analysts etc) willing to refer to the whole framework of the above standards.

2.2 Scope/Exclusions It is in the scope of this document to provide a brief description of the supporting deliverables and link them to the ICT Project Life Cycle. This is just a qualitative approach and does not determine the exact contents of the said deliverables. The deliverables do not focus into procedures and methodologies for Software Development, since Software Development is supposed to be done by external entities.

2.3 Assumptions It is assumed that the readers of this document are familiar with ICT projects design and management. Since the PLC description provided by this document covers both administrative and technical issues, it is also assumed that the contracting authority will undertake the appropriate actions for the institutionalization of the said ICT Standards.

2.4 Other Standards All of the related standards are listed in the current document at the appropriate positions.


3 Project Organization This section outlines the setup and organization of a typical systems development project. The terms and project roles identified here will be used throughout this document in the descriptions of each Phase of the PLC. A typical project organogram, including both the beneficiary side (a public sector entity, hereafter “Organization”) and the contractor side (if any) is depicted below:

Figure 1 - Typical Project Organization

The appropriate Names of the people fulfilling the project roles are to be inserted in the appropriate boxes of the project’s organogram, when this is to be included in the Project Plan document. The Project’s Organogram and structure may vary according to the nature of each specific project. The Project Roles and Responsibilities of a typical project are outlined in the next section.

3.1 Roles and Responsibilities

3.1.1 Executive Management

The role of Executive Management is filled by a Director, senior executive or a Steering Committee formed for an application development project. Its responsibilities are: � Accountability for the success of the project; � Resolving requests for decision;

Standards

Planning

Definition

AnalyzeDesign

Build

Implementation

Business analysisApps. administration

Data administrationOperations planningTechnical support

Are definitely with the Organization

May, or may not be with the Organization

Project sponsor

Business Champion

Executive ManagementSteering Committee

Proj. Man. /Impl. User Team QA Support

Project Manager Business Support

Implementation Experts

Implementation staff

QA

Techn. An Busin. An. Training expert(s)

Developers Consultants Trainers


� Resolving project resource allocation conflicts; � Monitoring project plans/schedules; � Providing strategic direction and plans; � Ensuring integration between business units; � Appropriate reviews of project deliverables.

3.1.2 Project Sponsor

� Reporting to director/executive or steering committee; � Setting project priorities; � Securing project funding; � Allocating project resources; � Final approval of all deliverables; � Approving the contracts (if applicable).

3.1.3 Business Champion

� Reporting to project sponsor; � Providing business area project direction; � Coordinating business area resources; � Approving project budgets; � Resolving project issues; � Presentations to the Executive Management; � Appropriate review and approval of project deliverables; � Communication.

3.1.4 Project Manager

The role of the Project Manager is to take overall responsibility for the success of all aspects of the project by: � Reporting to the project sponsor or business champion; � Assuming the primary responsibility for comprehensive project management; � Ensuring adherence to all the PLC phases, deliverables and standards; � Preparing project plans, schedules and budgets; � Coordinating project resource activity; � Managing/monitoring contractors; � Preparing/presenting project status reports (referring to the whole project); � Preparing/monitoring issues; � Preparing/monitoring change requests; � Preparing/monitoring requests for decision; � Quality assurance and signing-off of all deliverables; � Managing final acceptance testing. � Administering the project

3.1.5 Business Support

Advisors are to be included as appropriate by the Project Manager to assist with particular technical, architectural and/or business requirements and direction, in one or more of the following areas: � Business analysis; � Application architecture (if applicable); � Data administration (if applicable);


� Operations planning and support; � Technical support (if applicable). � Legislative change (if needed)

3.1.6 Implementation Team

The Implementation team will usually draw upon resources from contractor (if any) and partnering entities, contracted to supplement the project team.

Implementation Project Manager/Leader � As for Project Manager above, but restricted to the scope and responsibility of the

Development Team; � Status Report preparing here will refer only to the project scope assigned to the

Implementation Team; � Main Organization contact for the implementation team. � Assigning of work and monitoring of the time and quality of deliverables.

Business Analyst � Major contribution to the detailed analysis deliverable; � Understanding the Organization's business requirements; � Ensuring business/technical (IT) integration (if applicable); � Coordinating user testing (if applicable); � Major contributing to the deliverables of the implementation phase; � Participating in all PLC phases. � Giving recommendations on organizational change management.

Technical Analyst(s) (if applicable) � Major contributing to the detailed design deliverable; � Assisting with logical data model; � Preparing the physical data model; � Coordinating system testing.

Implementation Staff (Developers, Consultants, Trainers etc) � Major contributing to the system build deliverable; � Conducting unit testing (if applicable).

Quality Assurance on Implementation � Conducting internal deliverable quality reviews prior to delivering � Reviewing and approving all deliverables.

3.1.7 User Team

The User Team roles are defined depending on the requirements of the system and the business area being addressed. Each sub-team will be responsible for its portion of the business area and address the following responsibilities. � Defining business requirements; � Providing business direction; � Appropriate reviewing of project deliverables; � Major contribution to user documentation and testing plans (if applicable); � Participating in user and acceptance testing (if applicable).


3.2 Quality Assurance Quality Assurance (QA) is required for all Project Deliverables.


4 ICT - Project Life Cycle The ICT - Project Life Cycle (PLC) is intended to provide a set of guidelines for the successful completion of application development projects. The PLC consists of six distinct phases as shown in Figure 2 below:

Figure 2: PLC Phases Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6Planning Definition Analysis Design Build Implementation

Each phase contains one or more individual deliverables associated with the phase. These deliverables are themselves described in separate standards documents. The phases and the related deliverables may vary according to the nature and the budget of the project, but they can be adjusted to almost every case. An example for the case of a Software / integrated system implementation is shown in Figure 3 below, along with a summary of these deliverables, by PLC Phase and a checklist of the involved staff.

Figure 3: Software Development Deliverables and Standards Phase Deliverable Can this be outsourced Contributors1

Consultant SupplierPlanning Quality Assurance2

Feasibility Study Unlikely No BS Tender Document Yes No PM, BS Contract Document No No PM, BS

Definition Project Plan Yes Yes BS Analysis Requirements Specification Unlikely Yes BS, User T. PM

PM/Impl, BA

System Analysis document Unlikely Yes Data Migration analysis Yes Yes

Design Detailed System Design Unlikely Yes BS, User T. PM PM/Impl, BA, TAData Migration design Unlikely Yes

Build Complete System Architecture Definition

No Yes BS, PM PM/Impl, BA, TA, Impl. staff Application forms and

reports No Yes

Tested application No Yes Data conversion No Yes

Implementation Implementation plan Unlikely Yes BS, Users, PM PM/Impl, BA, TAOnline help text No Yes

User acceptance test Yes Unlikely User training planning Yes Yes User procedures No Yes Application delivery Unlikely Yes

The following figure (Figure 4) provides the same information about a training project.

1 Abbreviations: BS - Business Support, PM - Project Manager, BA - Business Analyst, TA - Technical Analyst 2 Quality Assurance is not actually a deliverable but a guide that must be followed for all deliverables. QA therefore contributes to all of the deliverables.


Figure 4: Consultancy Provision Deliverables and Standards Phase Deliverable Can this be outsourced Contributors

Consultant SupplierPlanning Quality Assurance

Feasibility Study Unlikely No BS Tender Document Yes No PM, BS Contract Document No No PM, BS

Definition Project Plan Yes Yes BS Analysis Training Requirements

Specification Unlikely Yes BS, User T. PM

PM/Impl, BA Training needs Analysis

document Unlikely Yes

Design Detailed Design (e.g. classes, trainers, timetables etc)

Unlikely Yes BS, User T. PM PM/Impl, BA

Build Training material development

No Yes BS, PM PM/Impl, BA, TA, Impl. Staff.

Implementation Training courses Unlikely Yes BS, Users, PM PM/Impl, BA

The following figure (Figure 5) provides the same information about a hardware purchase oriented project. Figure 5: Hardware Purchase Deliverables and Standards

Phase Deliverable Can this be outsourced ContributorsConsultant Supplier

Planning Quality Assurance Feasibility Study Unlikely No BS Tender Document Yes No PM, BS Contract Document No No PM, BS

Definition Project Plan Yes Yes BS Analysis Requirements Specification Unlikely Yes BS, User T. PM

PM/Impl

Analysis document Unlikely Yes

Design Detailed Design of hardware components

Unlikely Yes BS, User T. PM, TA

Build /Implementation

Implementation plan No Yes BS, PM PM/Impl, BA, TA, Impl. Staff. Users, PM/Impl, TA

Hardware delivery Unlikely Yes Implementation No Yes Migration No Yes Testing No Yes

Notice that, in the last case, the Phases “Build” and “Implementation” are merged.


4.1 Planning Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6Planning Definition Analysis Design Build Implementation

4.1.1 Purpose

This Phase of the PLC is required to: � Determine the feasibility of a particular project proceeding, or not (ICT Feasibility Study) � Prepare the Tender Documents for the particular project (if applicable) � Prepare the Contract Documents after a contractor has been selected (if applicable).

The Feasibility Study will produce a high-level overview document of the proposed project. It will contain information relating to the project’s requirements and will enable the formalization and definition of the scope of the project in a high level. Note: A project may be implemented internally. In such cases there are no Tender and Contract document deliverables.

4.1.2 Prerequisites

Identified Business Need

4.1.3 Deliverables

� Feasibility Study � Tender Document (if applicable) � Contract Document (if applicable)


4.1.4 Responsibility

The suggested responsibilities associated with this Phase are: Executive Management

Deliverables approval

Project Sponsor Secondary responsibility Business Champion Primary responsibilityBusiness Support Assist as required

Quality Assurance of deliverable Project Manager Assist as required and if available QA Support Standards User Team Required input Implementation Team

Project Manager Technical Analyst Business Analyst Implementation staff

QA Support

Are definitely with the Organization May, or may not be with the Organization

4.1.5 Milestones

� Project Approval � Tender issue (if applicable) � Contract signing (if applicable) A project must not proceed to the next Phase without the appropriate authorization and approval.

4.1.6 Remarks

This is the first Phase in the PLC. The Feasibility Study deliverable is the first major deliverable in the project. The Feasibility Study is to be produced prior to the commencement of a project. It is normally produced by Organization staff, such as a business analyst or application administrator, and is usually completed and approved prior to hiring a contractor for the project. It is advised that the issue of the Tender Document is preceded by a Public Consultation, in which a large exchange of ideas and clarifications will take place. The Contract document is mostly an Administrative one.

4.1.7 Activity

It is the Business Champion’s responsibility to ensure setup of the Feasibility Study. Together with appropriate members of the User Team, the Business Champion will provide information for the completion of the Feasibility Study.


The Project Sponsor is responsible for reviewing and approving the Feasibility Study and securing the necessary funding for the project. The draft Feasibility Study must be submitted to a team of advisors for Business Analysis review and it must meet predefined quality standards. The completed Feasibility Study will be submitted to the Executive Management for approval and budget allocation authorization. The same applies to the Tender Document. Contract Document must be also reviewed by the appropriate Administrative Authorities.


4.2 Definition Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6Planning Definition Analysis Design Build Implementation

4.2.1 Purpose

This Phase of the PLC defines exactly what, who, when and how the project will be carried out. This Phase will take the deliverable from the previous Phase (Contract Document), expand on the project outline and provide a specific and detailed project definition. This Phase is the first activity of the project after obtaining approval and funding to proceed. The description of this Phase assumes that the following associated activities have been completed: � Preparation and distribution of an Tender Document (if applicable); � Review of proposals and selection of a contract implementation team (if applicable); and � Appointment of a Project Manager. This Phase effectively communicates to project stakeholders the project scope and schedule, as well as any related risks or constraints.

4.2.2 Prerequisites

� Feasibility Study -- Approved. � Budget Allocation. � Contractor Selection (if applicable) � Project Manager Appointment.

4.2.3 Deliverables

Project Plan




Deliverable approval

Project Sponsor Deliverable Approval Business Champion Requirements Input Business Support Secondary Responsibility

Quality Assurance of deliverable Project Manager Primary ResponsibilityQA Support Standards User Team Requirements Input Implementation Team

Project Manager Technical Analyst Business Analyst Implementation staff

QA Support


4.2.5 Milestones

Project Plan -- Approval and Sign-off. A project must not proceed to the next Phase without approval of the Project Plan.

4.2.6 Remarks

This is the second Phase in the PLC, but the first Phase of the project itself. The Project Plan deliverable from this Phase must be completed and signed-off prior to commencing the next phase of the project. Refer to the Project Plan document for a detailed description of this deliverable. Agreement to the Project Plan ensures that everyone involved in the project is clear on the project scope, objectives, goals and outcomes.

4.2.7 Activity

The Project Manager is responsible for producing the Project Plan. However, the Project Manager may delegate this activity to the Implementation Team for completion. The Business Champion, Business Analyst and appropriate members of the User Team will provide project information to help complete the Project Plan. The draft Project Plan must be submitted to Business Support for Business Analysis review. The deliverable must meet predefined quality standards.


The completed Project Plan will be submitted to the Business Champion and Project Sponsor for approval and sign-off.


4.3 Analysis Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6Planning Definition Analysis Design Build Implementation

4.3.1 Purpose

This Phase of the PLC is required to understand and document the users' needs related to the project’s outcomes. This Phase will document, in significantly more detail than the Project Plan, the scope, business objectives and requirements of the current/proposed project. The emphasis throughout this Phase is on what is to be done and not on how. During analysis and specification, the technical aspects and constraints should be considered, but should not be influenced by implementation characteristics. The technical aspects of the project are addressed in the Design Phase. Note: In case of Software Development / Integrated system Implementation or Hardware purchase project, during this Phase the Data Migration requirements, at a high level, will become apparent. This will start a parallel set of PLC Phases for the Data Migration associated with the system. Data Migration will follow Phases 3 to 6 of the PLC. Depending on the size and complexity of the total project (system and data conversion) the Data Migration Application could be incorporated as a section or component of the main System Design deliverable, or become a separate Data Migration deliverable of its own. Operational requirements will also be identified during this Phase.

4.3.2 Prerequisites

Project Plan -- Approved.

4.3.3 Deliverables

� Requirements Specification � Detailed Analysis document � Data Migration Analysis (if applicable)




Monitor Progress

Project Sponsor Support the Process Business Champion Direct, Approve Significant Contribution Business Support Secondary Responsibility

Major Contributor Project Manager Primary Responsibility

Quality Assurance QA Support Standards Quality Assurance User Team Significant contribution Implementation Team

Project Manager Secondary Responsibility Technical Analyst Assist (not applicable in case of training or other services oriented

project) Business Analyst Major contribution (not applicable in case of hardware purchase

oriented project) Implementation staff

QA Support Analysis standards


4.3.5 Milestones

Detailed Analysis -- Approval and Sign-off A project must not proceed to the next Phase without appropriate deliverable approval and Sign-off.

4.3.6 Remarks

The Detailed Analysis is to be stated in language that reflects the background of the user base. Most requirements are written as plain business language sentences supplemented with diagrams, graphics and tables of detailed information.

4.3.7 Activity

The Project Manager is responsible for producing the deliverables associated with the Detailed Analysis. However, the Project Manager usually delegates this to an appropriate person of the Implementation Team (e.g. in case of Software development project, to the Business Analyst). This deliverable has significant input from the Business Champion and User Team. Irrespectively if some or all of the Phase's deliverables have been delegated, the Project Manager maintains overall responsibility for producing quality deliverables submitted to the Business Champion for review and sign-off, and to QA Support for Quality Assurance.


The Project Manager will provide initial Quality Assurance of the deliverable prior to review by QA Support, User Team and the Business Champion. The draft Detailed Analysis must be submitted to the Business Support and Quality Assurance for Data Administration review and Quality assurance against standards. The completed Detailed System Analysis will be submitted to the Business Champion and Project Sponsor for approval and Sign-off.

4.4 Design Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6Planning Definition Analysis Design Build Implementation

4.4.1 Purpose

This Phase of the PLC continues from the Detailed Analysis and describes how the proposed project will be implemented. In case of Software Development project, the Design is specific to the technical environment that the system will operate in and the tools used in building the system. The results of this Phase significantly impact the Build and Implementation Phases of the system.

4.4.2 Prerequisites

Detailed System Analysis -- Signed-off

4.4.3 Deliverables

� Detailed Design. � Data Migration Design (if applicable).



The suggested responsibilities associated with the Design Phase are: Executive Management

Monitor Progress

Project Sponsor Support the Process Business Champion Review, Approve Business Support Secondary responsibility Project Manager Primary Responsibility

Quality Assurance QA Support Standards User Team Review Implementation Team

Project Manager Secondary Responsibility / Implementation team Major contributor

Technical Analyst Major contribution Business Analyst Assist (not applicable in case of training or other services oriented

project) Implementation staff

QA Support Design Standards


4.4.5 Milestones

Detailed Design -- Approval and Sign-off. A project must not proceed to the next Phase without appropriate deliverable approval and sign-off

4.4.6 Activity

The Project Manager is responsible for producing the deliverables associated with the Detailed Design. However, the Project Manager usually delegates responsibility for some or all of these deliverables to the Implementation Team. Irrespectively if some or all of the Phase's deliverables have been delegated, the Project Manager maintains overall responsibility for producing quality deliverables submitted to the Business Champion for review and sign-off, and to QA Support for Quality Assurance. The Project Manager will provide initial Quality Assurance of the deliverable prior to review by QA Support, User Team and the Business Champion. The draft Detailed Design must be submitted to Business Support and Quality Assurance for Data Administration review and QA against standards.


The completed Detailed Design will be submitted to the Business Champion and Project Sponsor for approval and Sign-off.


4.5 Build Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6Planning Definition Analysis Design Build Implementation

4.5.1 Purpose

Depending on the nature of the project, this Phase of the PLC deals with the development, unit testing and integration testing of the application or the elaboration of the studies, training material etc. In addition, if the project is related to software/integrated system/hardware purchase, this Phase addresses the preparation and establishment of the technical environment for development, testing and training of user representatives. This Phase is often carried out in parallel with some activities of the Implementation Phase. Coordination of the Build and Implementation Phase activities is a key responsibility of the Project Manager at this time. Any special procedures for data conversion and/or data warehousing are also developed and tested. The process of developing and testing the data conversion and data warehousing modules is no different from that required for the system itself.

4.5.2 Prerequisites

Detailed Design - Signed-off.

4.5.3 Deliverables

Following list of deliverables apply in case of Software Development/integrated system project: � Complete System Architecture Definition � Application forms and reports � Tested application and System environment. � Data Migration (if any) Following list of deliverables apply in case of a Training project: � Training Material Following list of deliverables apply in case of consultancy project: � Study deliverables as described in the Detailed Design deliverable.



Monitor Progress


Quality Assurance QA Support Standards


User Team Review Implementation Team

Project Manager Secondary Responsibility / Implementation team Major Contributor

Technical Analyst Assist (if applicable) Business Analyst Assist Implementation staff

Major contributor

QA Support Build Standards


4.5.5 Milestones

Deliverable Build -- Approval and Sign-off. Some activities in this Phase may be conducted in parallel with activities of the Implementation Phase.

4.5.6 Activity

The Project Manager is responsible for producing the deliverables associated with the Build Phase. However, the Project Manager usually delegates responsibility for some or all of these deliverables to the Implementation Team. Irrespectively if some or all of the Phase's deliverables have been delegated, the Project Manager maintains overall responsibility for producing quality deliverables submitted to the Business Champion for review and sign-off, and to QA Support for Quality Assurance. The Project Manager will provide initial Quality Assurance of the deliverables prior to review by QA Support, User Team and the Business Champion. The draft Phase deliverables must be submitted to Business Support for technical review and to QA Support to review quality assurance against standards. The completed System Build will be submitted to the Business Champion and Project Sponsor for approval and sign-off.


4.6 Implementation Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6Planning Definition Analysis Design Build Implementation

4.6.1 Purpose

This Phase of the PLC is to prepare for and carry out the implementation of the developed system/deliverable/service to operation. In case of software development/hardware purchase this is done through user and acceptance testing. In case of a training project, this phase relates to the training courses. In case of a consultancy service (e.g. Process Reengineering) this phase relates to pilot operation.

4.6.2 Prerequisites

N/A

4.6.3 Deliverables

Deliverables of this phase vary upon the nature of the project. As an example, in case of software/integrated project, the following deliverables apply: � Implementation plan � User procedures � Online help text � User acceptance test � User training planning and execution � Application delivery � Migrated data (if applicable) � Production Sign-off. In case of hardware purchase project, deliverables are as follows: � Implementation plan � List of equipment delivered � Acceptance test � User training planning and execution In case of a training project, deliverables may be: � Training records � Evaluation of trainers � Evaluation of trainees � Certificates




Monitor Progress


Quality Assurance / Change Control. QA Support Standards QA User Team Review, Approve, Test Implementation Team

Project Manager Primary Responsibility / Implementation team Technical Analyst Major contribution (not applicable in case of training or other services

oriented project) Business Analyst Major contribution Implementation staff

Major contribution

QA Support Production QA


4.6.5 Milestones

� Data Migration (if applicable) -- Approval and Sign-off. � System Production (if applicable) -- Approval and Sign-off. � Pilot Operation (if applicable) completed � Contract Closure A project must not close without appropriate authorization and approval.

4.6.6 Remarks

This is the last Phase in the PLC. This Phase will provide users with the documentation and training required to use the system effectively. Individual system components that successfully passed unit and integration testing during the Build Phase are now subjected to a more rigorous system and acceptance testing, as defined by the testing plan. In addition, user and operation procedures are tested for the system. As appropriate, the Data Migration (if any) will only occur once and be performed prior to the finalization of the system into Production. The detailed Data Migration and Implementation Plans will define exactly how this will be accomplished. In case of training projects or system implementation projects involving large scale training, trainees are demanded to rate themselves as well as the trainers and the training program.


Before contract closure, it is highly recommended that the Implementation Phase includes a Supported Operation period (if applicable), during which appropriate members of the Implementation Team will assist the users in their daily work.

4.6.7 Activity

The Project Manager is responsible for producing the deliverables associated with the Implementation Phase. However, the Project Manager usually delegates responsibility for some or all of these deliverables to the Implementation Team PM. Irrespectively if some or all of the Phase's deliverables have been delegated, the Project Manager maintains overall responsibility for producing quality deliverables submitted to the Business Champion for review and sign-off, and to QA Support for Quality Assurance. The Project Manager will provide initial Quality Assurance of the deliverables prior to review by QA Support, User Team and the Business Champion. The draft System Build must be submitted to Business Support for technical review and to Quality Support to review quality assurance against standards.


4.7 After project closure activities After the project closure, a number of important activities take place to ensure the sustainability of the project’s outcomes as well as the continuous improvement of the Organization’s information infrastructure. These activities include: � Maintenance procedures, � Survey and evaluation of existing or planned systems, � Systematic assessment of existing systems, � Master Plan elaboration for the next period etc


5 Supporting Documents Apart of the standard PLC documents mentioned above, there is a number of supporting documents, which aim at the clarification of some aspects of either of the Project Life Cycle or of its context. This section describes in brief the above documents and their relation with the PLC.

5.1 ICT Project Management Project (Contract) Management covers Phases 2 – 6 of PLC. ICT Project Management in public administrations does not employ the full range of Project Management processes, tools and techniques but rather several of the ones pertaining to executing, monitoring and controlling, and closing of a project. On the other hand, ICT Project Management is very much dependent on project size, which affects the project’s organization structure. This has to be consistent with the size of the project and adequate to the relevant organization of the party responsible for project implementation so as to: � Provide with correspondents at each level of the organization that will facilitate the day-to-

day execution of project activities and assist the decision making process; � Ensure that project communication is executed seamlessly in all channels and different

levels of hierarchy. ICT Project Management for public administrations aims at providing a system (referred to as a project management system) which is a set of tools, techniques, methodologies, resources and procedures used to monitor and control the project. This system must cover in principle the major areas of concern for the project owning organization, such as: � Project organization aspects and the relevant communication plan and principles; � Monitoring of project activities and performance measurement during their execution; � Identification of potential risks, their assessment and their management including possible

mitigation methods; � Change management procedures and techniques and issue resolution; � Project acceptance principles and procedures; � Project reporting and archiving of relevant documentation; � Project closure procedures and transfer of ownership of project results. The above form a framework for the efficient monitoring and controlling of ICT projects and contribute to successful project implementation.

5.2 ICT Project Closure The purpose of this document is to provide a template and guidelines for performing ICT project closure. This is the final stage of a project, and aims to the evaluation of: � The project’s results, � The methodology and tools used for conducting the various aspects of the project (e.g.

software development, project management etc) � The individual performance. The results of the above evaluation should be used as inputs in the following areas: � ICT Planning (Master Plan, Feasibility Study, Project Charter, project Plan) � Methodology and Standards adaptation � Resource Management


� Small improvement tasks an projects

5.3 ICT Software Applications The large Public Sector Organizations have a common set of organization elements and functions, which refers mostly to their background operations. Furthermore, many software packages have been developed to serve the organizations’ common needs (off-the-shelf software). The most common packages used in Public Sector include: � Accounting and budgeting Systems � Human Resource management and Payroll � Assets management � Purchase management � Workflow and document management systems These packages, to address the stakeholders’ needs, must offer specific functionality and meet certain quality criteria. Their functionality must derive from the Business Function Analysis of the Organization, and their quality criteria must meet the architecture’s perspectives as they are shaped by the User Requirements. The same criteria apply also to custom software, which usually address the Organizations’ core business functions. The similarity of almost all of the Organizations’ background functions and procedures information needs, allows the establishment of a common set of requirements to be used across the whole Syrian Public Sector. The result is conformance tables to be included in the Tender Document (after some revision and adaptation to the specific case). This procedure, is not only helpful in avoiding time-consuming work, but also improves requirements’ quality.

5.4 ICT Common Codification Schemes ICT Common Codification Schemes address the need of an Organization to use either common data, or, at least, commonly codified data to support the interoperability of its ICT systems. Common data in the public sector may cover areas such as: � Administrative regions � cities, villages, roads, streets � Person Identification and location � Public Sector Entities codification � Private Companies identification Generally the needs of each application in depth of codification analysis vary according to the significance of the specific data, as well as their processing. In any case common codification must be as analytic as the most demanding application needs, and data from other applications must be migrated to the chosen codification scheme.

5.5 ICT Business Function Analysis The description of the organization and its function and processes is essential for understanding the stakeholders (acquirers, users, EDP dept.) and their needs. Furthermore, the introduction of an ICT system in the organization changes the flows and the rules of the organization’s procedures; hence a clear view of how the whole “TO BE” system will work is essential for its understanding and documentation.


This document aims at providing sample methodology and modelling techniques to carry out a Business Function Analysis, used in Feasibility study, Requirements specification etc as appropriate.

5.6 ICT Data Modelling ICT Data Modelling is the most commonly used tool to represent data structures in a well understandable way. Although it is a static model, with no representation of the data processing, it is very useful for: � Exploring data (usually using views) and building new reports � Verifying constraints � Perform a Relational Analysis (i.e. verifying that the data and their structure comply with

the Organizations needs) � Upgrading existing applications and/or building new applications based on existing data

structures. � Data Migration Analysis and Design, etc. This document describes sample methodology and modelling techniques related to Data Modelling, used particularly in System Analysis and Design.

5.7 Systematic Assessment of Existing Systems The purpose of this document is to provide a template and guidelines for performing existing information systems assessment. The results of this assessment may serve to: � Identify weaknesses of the existing systems and initiate improvement activities � Decide whether existing systems need replacement, enhancement or may continue to be

functional in an updated information environment. This is usually part of the work to be done during the Master Plan and/or Feasibility Study elaboration.

It is out of the scope of this document to provide an approach in evaluating other Information System related fields, such as: � Organization’s Information Strategy � IS Facility infrastructure � IS Management infrastructure IS facility and IS Management infrastructure will be covered in the “ICT Survey and Evaluation” document.

5.8 ICT Maintenance This document aims at providing structured methods and procedures for the maintenance of ICT systems from both technical and organizational point of view. The proposed standards will mostly serve as reference material for the feasibility study and tender documents, as well as for the establishment of a solid support and maintenance framework for the Syrian ICT installations.

5.9 ICT Security Standards This document aims at providing a consistent methodology on Security Policy and standards for the Syrian public sector, and also provides a set of best practices in Security planning and implementation. The proposed standards may also serve as an input for: � The Feasibility study � The Tender and Contract Documents � The Requirements Specification, Analysis and Design of an ICT System


5.10 ICT Survey and Evaluation This document provides checklists and guidelines about survey and evaluation of existing or planned ICT Systems. Survey and evaluation is performed in the following areas: � Evaluation of ICT systems (either existing or planned) against the Organization’s ICT

Policy � Evaluation of ICT resources. � Evaluation of ICT practices (maintenance, standards etc) The purpose of the ICT Survey and Evaluation methodology is to ensure that the ICT infrastructure and services (either existing or planned) of a given organization are in accordance with the organization needs. There is a partial overlap between the tasks described in this document and the task that have to be performed when elaborating a systematic assessment of existing systems and/or an ICT Master Plan. Thus, it is recommended to plan the related tasks in a way that the same work is not done twice and the results can serve multiple purposes (e.g. the ICT Survey and Evaluation outputs may be an input for the ICT Master Plan).

5.11 ICT Master Plan This document aims at defining the structure and contents of an ICT Master Plan. Typically, a Master Plan contains the analysis of the “AS IS” situation, a SWOT Analysis and the analysis of “TO BE” situation in terms of functionality, ICT infrastructure, expected benefits and cost, high level schedule of actions as well as the change management needs to fill the gap. A Master Plan describes a set of (usually) related ICT projects. Each one of these projects may be initiated to follow a complete Project Life Cycle as described in Session 4.


6 Conclusion The phases of the Project Life Cycle (PLC) of various ICT projects (software / integrated system implementation, hardware purchase, training projects etc) have common characteristics and can be approached in a structured way. Documentation and appropriate approval of the results of each phase is essential for achieving project’s goals and manage any changes or issues. Although project closure flags the end of the project’s life cycle, survey and maintenance activities are imperative both for turning to account the benefits resulting from the project as well as for further improvements.

ICT Introductory Document Appendix A – Page 30 ISMF-ICT / ISMF - ICT Standards

7 Appendixes

7.1 Appendix A – ICT Standards Deliverables The following table summarises the deliverables to be submitted, and distinguish whether they are part of the Project Life Cycle standards or supporting ones. Number Major deliverable PLC Deliverable Supporting

Deliverable

3.03 ICT Security Standards ICT Security Standards (§ 5.9)

3.04 ICT Business Function Analysis

ICT Business Function Analysis (§ 5.5)

3.05 ICT Planning and Analysis � Requirements Specifications

� Analysis � Design

3.06 ICT Software Applications ICT Software Applications (§ 5.3)

3.07 ICT Data Modelling ICT Data Modelling (§ 5.6)

3.08 ICT Common Codification Schemes

ICT Common Codification Schemes (§ 5.4)

3.09 ICT Data Migration � Data Migration Analysis

� Data Migration Design

3.10 Systematic Assessment of Existing Systems

Systematic Assessment of Existing Systems (§5.7)

3.11 ICT Maintenance ICT Maintenance (§ 5.8)3.12 ICT Feasibility Study Feasibility Study 3.13 ICT Master Plan ICT Master Plan (§

5.11) 3.14 ICT Tender Document(s) Tender Document 3.15 ICT Contract Document(s) Contract Document

3.16 ICT Project Management Project Plan ICT Project Management (§ 5.2)

3.17 ICT Acceptance Procedures Acceptance Procedures 3.18 ICT Project Closure ICT Project closure (§

5.2)

ICT Introductory Document Appendix A – Page 31 ISMF-ICT / ISMF - ICT Standards

Number Major deliverable PLC Deliverable Supporting Deliverable

3.19 ICT Survey and Evaluation ICT Survey and Evaluation (§ 5.10)

ICT Introductory Documentmoct.gov.sy/ICTSandards/en_pdf/1.pdf · 2008. 5. 17. · The ICT Project...

Documents

Transcript of ICT Introductory Documentmoct.gov.sy/ICTSandards/en_pdf/1.pdf · 2008. 5. 17. · The ICT Project...