ICT Processes Standard Operating Procedures and Good Practices

Prepared In January 2002 By OMSAR

Table of Contents
1.0 Preliminary and Administrative Activities ................................................ 1 Activity 1 : Define Business Objectives as Related to ICT ................................. 2 Activity 2 : Initiate and Plan the Good Practices Project ................................... 3 Activity 3 : Collect Documents Relevant to the Project ..................................... 5 Activity 4 : Conduct Risk Management for the Good Practices Project................. 6 Activity 5 : Establish Proper Communication Schemes ..................................... 8 Activity 6 : Setup a Performance Measurement Process ................................. 10 Activity 7 : How to Implement Standards .................................................... 12 Activity 8 : How to Manage ICT Projects ...................................................... 14 Activity 9 : Setup the Configuration Management Process .............................. 16 Managing ICT Human Resources ............................................................ 19 Activity 10 : Organize the Structure of the ICT Unit....................................... 20 Activity 11 : Identify the Required Competencies per Position......................... 22 Activity 12 : Identify Actual Competency Levels of all Staff ............................ 24 Activity 13 : Analyze Competencies to Identify Training Requirements ............. 26 Activity 14 : Identify Training Resources...................................................... 28 Activity 15 : Manage Training Material......................................................... 29 Activity 16 : Maintain Training Records........................................................ 30 Activity 17 : Define Recruitment Standards.................................................. 31 Relationships with Suppliers .................................................................. 32 Activity 18 : Prepare a List of Supplier Products and Services ......................... 33 Activity 19 : How to Audit or Qualify Suppliers ............................................. 35 Activity 20 : Prepare an Agreements Register............................................... 38 Activity 21 : Evaluation of Suppliers, Products, Projects or Alternatives ............ 40 Activity 22 : Recommended Issues to Consider in ICT Agreements .................. 42 3.1 Including Technical Specifications in Agreements ................................ 42 3.2 Schedule and Timing of Product Deliveries ......................................... 42 3.3 Costing and Other Financial Issues ................................................... 43 3.4 Software Upgrades and Updates ....................................................... 44 3.5 The Supply of Source Code .............................................................. 44 3.5.1 Suggested Solutions ............................................................. 45 3.5.2 Data Structure vs Source Code............................................... 45 3.6 Maintenance and Warranty Services.................................................. 46 3.6.1 Warranties and Maintenance on Equipment .............................. 46 3.6.2 Warranties and Maintenance on Software................................. 46 3.6.3 Terms Applying to Both Hardware and Software........................ 47 3.7 Support Agreements ....................................................................... 47 3.8 Ensuring Continuity of Services ........................................................ 48 3.9 Delivery and Acceptance Criteria ...................................................... 48 3.10 Authorization of Staff ...................................................................... 49 3.11 Copyrights and Intellectual Property ................................................. 49 Qualification Processes .......................................................................... 51 Activity 23 : Specification Qualification (SQ) ................................................ 53 Activity 24 : Installation Qualification (IQ) ................................................... 56 Activity 25 : Operational Qualification (OQ).................................................. 58 Activity 26 : Performance Qualification (PQ)................................................. 60 Logical System Access and Security ....................................................... 64 Activity 27 : Identify Functions to be Secured .............................................. 65 Activity 28 : Assign Privileges and Access Rights........................................... 67 Activity 29 : Assign, Distribute and Control Passwords................................... 68











Activity 30 : ISO Standards for Security ...................................................... 70 Physical System Protection, Access and Security ................................... 72 Activity 31 : Infrastructure – Server and Other Rooms .................................. 73 Activity 32 : Infrastructure – Cabling .......................................................... 75 Activity 33 : Infrastructure – Networks........................................................ 76 Activity 34 : Assign Physical Access Privileges .............................................. 78 Activity 35 : Assign, Distribute and Control Passwords................................... 80 Activity 36 : Insure the ICT Systems........................................................... 81 Information Integrity : Backup / Archiving and Data Protection............ 82 Activity 37 : Identify What is to be Backed Up and When ............................... 83 Activity 38 : Backing Up ............................................................................ 85 Activity 39 : Identify What is to be “Restore Tested” and When....................... 87 Activity 40 : Restore Testing ...................................................................... 89 Activity 41 : Good Back Up Practices ........................................................... 91 Activity 42 : Protection Against Viruses ....................................................... 93 Information Integrity : Business Continuity Planning ............................ 94 8.1 Business Continuity Plans ................................................................ 94 8.2 Classifying Disasters ....................................................................... 94 Activity 43 : Disaster Recovery Procedures .................................................. 96 Activity 44 : Disaster Recovery – Good Practices .......................................... 99 Activity 45 : Business Continuity – Contingency Plans ................................. 100 Software Application Development ...................................................... 101 Activity 46 : Using a Software Development Process ................................... 102 Activity 47 : Software Development Tools.................................................. 104 Activity 48 : Programming Standards ........................................................ 105 Activity 49 : Selecting Software Applications .............................................. 107 Operations Management ...................................................................... 109 Activity 50 : Logging Maintenance and Support .......................................... 110 Activity 51 : Control Dissemination of Hard Copies and Distribution ............... 113 Activity 52 : Good Practices for User Support ............................................. 115 Activity 53 : Managing the Supplies of the ICT Systems............................... 117 Activity 54 : Documenting Data Entry Procedures ....................................... 118 Activity 55 : Standard Data Entry Checks and Controls ................................ 120 Activity 56 : Using and Supporting Office Technology Products ..................... 121 Environment Management ................................................................... 123 Activity 57 : Define the Required Environmental Conditions.......................... 124 Activity 58 : Monitor Environmental Behavior ............................................. 126

0 Preliminary and Administrative Activities The Guide commences with a set of Activities that are general. The ICT Processes Page 1 . Most are fundamental processes in that they apply to the whole Department.1. They do not fall under any specific Information Process.

using them in the wrong manner or even not estimating budgets properly. Documentation and Deliverables : prepare a document that responds to the above questions and any others that the Department finds crucial.Activity 1 : Define Business Objectives as Related to ICT Objectives : this Activity defines the steps needed to establish Policies and Goals for using its current and projected ICT Systems. Risks : should such goals and policies not be defined. This Activity also assesses the degree to which business/organizational plans and ICT plans are aligned. changes to existing systems. It determines the appropriateness of the mechanisms for establishing the priorities of ICT investments (New projects. Such a document would therefore establish the ICT strategy and plan for the Department. the Department risks acquiring the wrong systems. Questions such as the following should be asked and answered : • • • • • • • • • • • What is each ICT System for? What does the Department expect from each system? How do the systems impact the general strategy of the Department? Who are the beneficiaries of the Department’s ICT Systems? What are the Technologies selected for current and projected systems What is the justification for such selection? (Financial and otherwise) How does each system contribute to the Products and Services the Department is to provide to the Citizen? Or to other Departments? Or to the outside world? What are the key performance indicators to be measured and tested to establish the success of the system? What are the challenges facing the ICT Systems? What are the main risks facing the implementation of the Systems? What is the structure of the ICT unit setup to handle all the ICT processes? Scope of usage : to cover all ICT Systems under current use or that are projected for future use. etc). The ICT Processes Page 2 . Of critical importance is an assessment of ICT spending. It establishes the governing rules and structure of the ICT unit as a whole.

in the case where the Unit has not been formed yet. the Management may find other parties for this role. Risks : should the Department not plan the Good Practices project properly. project management. Standard Operating Procedure : 1) 2) Define the Project Scope. executed and monitored. Scope of usage : restricted to the Good Practices Project. The Department will benefit from an ongoing application of Good Practices. This is a serious situation and can be known in advance. However. electronic documentation support. It is suggested that the Department contact OMSAR in such a case to study various other alternatives such as outsourcing. etc. The Good Practices to be implemented in the Department should form part of a long term Project that is well planned. Assign a capable Project Manager. authorities. The Project will not be involved in any other ICT projects except in so far as it may propose and implement good practices for them. it risks the following : • • • • • • • Undefined or unclear scope of the Project (Too wide or too narrow) Undefined or unclear deliverables Undefined or unclear communications channels Undefined or unclear authorizations Improper scheduling of the the Project Poor definition of a Project Team : responsibilities. Critical Risk : one of the major risks involved is that of the Department not having a Project Manager nor being able to assign a Project Team for the Project. this would be the Head of the ICT Unit. To do that. Identify all stakeholders of the project.Activity 2 : Initiate and Plan the Good Practices Project Objectives : the Good Practices Project is an ongoing process. Ensure that the Project Objectives are understood by all stakeholders or persons with active interest in the project. 3) 4) 5) The ICT Processes Page 3 . etc. The objectives of this Activity are to plan the Good Practices Project according to modern project management techniques. Objectives and Goals. refer to the document developed in Use the document arrived at in Activity 1) Analyze the Guide of Good Practices to identify the ICT Processes of interest to the Department and to determine the Activities that the Department needs to implement. Improper acquisition of resources required by the Project such as documentation. etc. assistance by other Departments. Usually. Stakeholders are all parties within and outside the Department that may have a positive or negative interest in the Project.

authorities as well as their lines of reporting. Define and establish the three main elements of any project. Assumptions often relate to various aspects of the Project or the ICT Processes. Typical roles in the team can be : Management Staff from the ICT Unit Quality assurance or Internal auditors or inspectors The units in which the systems are used Refer to the note at the beginning of this Activity that points to the risk of not being able to identify or assign such a team. Identify all Project constraints. The assumptions are the “Implied” needs of various Stakeholders. Ensure that the Project Manager has a good experience in the above activities. State all assumptions. 9) 10) 11) 12) Some of the above activities will be expanded as specific Activities in the following pages. scheduling and sequencing of Activities The estimates of the costs and resources needed to complete the Project 7) 8) Highlight all exclusions : these are usually functions within the Project that some stakeholder will “assume” are part of it but may not be. Documentation and Deliverables : the above definitions result in a Project Plan. The ICT Processes Page 4 . Convert implied needs to stated needs or drop them from the Project. their responsibilities. Good Practices and Recommendations : it is always critical to implement modern Project Management practices. Identifying them at this stage would save a lot of time and avoid disputes. This would reduce the Quality of the Project. Acceptance Criteria : this Activity is considered accepted when a Project Plan is approved. This has to be documented and circulated to all Stakeholders for final approval. define the Project Team. The Department may find that there are other Activities it needs to implement as Good Practices which are not mentioned in this Guide. This would be the right time to identify such Activities and add them to the overall list required by the Department.6) Identify Alternatives and Options to such Activities. Assumptions usually hide “implied” needs and cause gaps between what was promised and what was delivered. These consist of the core elements of the Project Plan : The functions and features of the Project (Deliverables) The phasing. Carry out Risk Analysis and Manage the Risks. (Refer to Activity 4) Based on the above.

The Register would include the document names. time would be lost during the completion of the various activities to collect and bring them up to date. Standard Operating Procedure : 1) Identify all existing documents that should be used such as : Department charter Ministerial decrees Various lists and registers Studies relevant to the ICT Systems Mission statements Vision statements Goals and Objectives Strategies for reaching such goals 2) Catalog such documents under a Register until they are subsumed under the proper Activities. Risks : should such documents not be available nor be up to date. 3) Documentation and Deliverables : all the above documents along with the Register that identifies them. Scope of usage : documents related to the Department as a whole as well as to the ICT Systems in use by the Department. status and location. Ensure that all documents are up to date. The ICT Processes Page 5 . Such documents should be verified to be correct and up to date. type.Activity 3 : Collect Documents Relevant to the Project Objectives : to collect all documents that will be of use during the various stages of the Good Practices project.

Find the Exposure : Multiply the Risk (From Step 2) by the Impact (From Step 3) for each event. an impact should also be assessed in terms of the financial or time loss it might cause. there are two events have 70% impact each. the Department should not be concerned with Risk Management for its own ICT Systems. Scope of usage : the whole Project itself. This is the exposure of the Department to this risk. the Department is bound to face many unknowns. Here follows a summarized procedure of Risk Analysis and Management : 1) 2) Identify all events which may damage the Project Assess the Risk or the likelihood or probability of each event taking place. This Activity presents a procedure for analyzing and mitigating the risks facing the Department. One results in a $200. For information’s sake. A detailed discussion of Risk Management is presented in the Appendix of Supplementary Material of Supplementary Material. List all Risks sorted by decreasing Exposure 3) 4) 5) 6) The ICT Processes Page 6 . For example. This is expressed as a percentage ranging from 0% (Not likely at all) to 100% (Certain to take place). Spending too little or too much time analyzing Risks Closing down the Project or specific Activities if major risks are found rather than attempting to resolve them Hiding risks from the eyes of the Management Improper assessment of probabilities and impacts. Risk Management should be carried out by the Project Manager. Note that at this moment. Risks : • • • • • Not being aware of how Risk Management takes place. Assess the Impact on the project should each event take place. This will be a number that is between 0% and 100%. Risk analysis for the ICT Projects of the Department should be handled within those projects. This is useful because it gives the Department a better way of assessing impact. This would allow it to avoid problems during the later stages.000 loss while the other results in a 50 day delay. Impacts are assessed as a percentage that ranges from 0% (No significant impact at all) to 100% (Catastrophic impact). Standard Operating Procedure : Follow the details provided in the Appendix of Supplementary Material of Supplementary Material.Activity 4 : Conduct Risk Management for the Good Practices Project Objectives : in the early stages of the Good Practices project.

The purpose would be to learn from earlier analysis as well as to ensure that (a) none of the risks are still likely and (b) there are no new risks. Good Practices and Recommendations : 1) Ongoing Review of Good Practices Project : review Risk Analysis during all stages of the Project.7) 8) Compute the Total Exposure of the Project by adding all Exposures. The ICT Processes Page 7 . Acceptance Criteria : upon submission of the Risk Analysis document along with the proposed solutions to all risky events. Risk Analysis for the Rest of the ICT Systems : should be carried out on the ICT Systems should any of the following situations arise : • • • • • • • New projects are launched Before the commencement of every major phase Troublesome spots are found in a Project New management take over the Project New software or systems are introduced Changes in the organization take place Changes in technology take place 2) Risk Analysis cannot be underestimated. this Activity would be considered complete. This can be managed by reducing the probability and/or by reducing the impact. Documentation and Deliverables : a risk analysis document for the project as per the structure proposed in the Appendix of Supplementary Material of Supplementary Material. Address the topmost exposed events and find ways to manage the risk. It is usually the only way to avoid future problems.

the following risks may arise : • • • • • Improper implementation of the Project Plan Lost information Activities that are not properly carried out nor completed Disputes between concerned parties Improper monitoring of the Project and hence loss of control Standard Operating Procedure : 1) Issue the Project Charter : this is a document that formally recognizes the existence of the Project and is the trigger for its launch : • • • The Charter is generally in the form of a memo or a letter by the Management It clearly identifies the Project Champion or the main driving force behind the Project and would probably be issued by that person. The objective of this Activity is to define the Communications schemes of the Good Practices Project. The ICT Processes Page 8 . date of authorization. the ICT personnel who will assist the Project Team. etc. Define the roles and responsibilities of each person on the Project Define the communication level to be established within the Project : What information to distribute? Who to send it to? When to issue letters.Activity 5 : Establish Proper Communication Schemes Objectives : Since the Project relies heavily on following “Quality” practices. Documentation and Deliverables : the documents listed in the above SOP.? Who is to issue such documents? Who gets copied? Where is the communication stored? What registers control the issue of such communications? 3) 4) 5) Identify the repository where such documents are to be kept and archived. Risks : should the Department not have a proper Communications scheme for the Project. Project Manager’s name. other parties outside the Department. a brief scope statement for the Project. minutes. analyses. it follows that Communication between all concerned parties has to be properly defined for the overall project. It lists other elements such as : the Project’s title. key Users. Scope of usage : the scope of the Project. a summary of the planned approach for managing the project. the Project Team. reports. 2) Prepare a list of all persons involved in the project : the Management Responsible for the Project. contacts and duties.

Good Practices and Recommendations : it is best that electronic copies be kept of all such documents. key documents should be subsumed under the Configuration Management activity. The ICT Processes Page 9 . the Project Manager and all involved parties. Acceptance Criteria : the Activity is considered completed when all the documents mentioned in the above SOP are collected and approved by the Management. Furthermore.

Number of vouchers entered in one day. the Department will need to look into what is causing such errors and remedy the cause. The ICT Processes Page 10 . if the proportion of erroneous vouchers reaches more than 10% of the total. week or month Number of documents returned per month because of error Number of complaint cases raised against the department per year Volume of transactions handled by the server per hour Measurement Schemes : develop a document that defines how each of the measurements can be taken and recorded. Examples : • • • • • 3) Citizen satisfaction as measured by an index usually prepared through a survey and computed using the Weighted Index Scoring Procedure (Refer to the Appendix of Supplementary Material of Supplementary Material). The figure of “10%” is thus an indicator. More importantly. For example. However. The decision making zone is any measurement above 10%.Activity 6 : Setup a Performance Measurement Process Objectives : Performance Measurement is one of the key managerial techniques in the modern world of organizations. these are usually grouped in 4 major areas : Financial areas Citizen based areas Internal Business Processes (Operations including ICT indices) Learning and Growth (Includes Human Resources) 2) Prepare the Metrics for each of these areas. What a Department can measure. Based on the currently popular Balanced Scorecard. Scope of usage : all aspects of work involving ICT. define within the document the Indicators that help the Department recognize whether particular measurements are within or outside decision making areas. there is no reason why the same methods cannot be used for other non-ICT processes in the Department. it can manage. Risks : not introducing a performance measurement scheme may lead to the following risks : • • • • Measuring the wrong things Using the measures for the wrong reasons or taking the wrong decisions Taking measures irregularly resulting in fragmented series Not having the proper information about various processes Standard Operating Procedure : 1) Identify the Areas of Concern the Department needs to measure. This Activity presents how a Department can prepare various metrics needed for performance measurement of ICT Systems.

When problem areas are identified through such measurements. tables or databases. develop remedial actions to resolve them. Good Practices and Recommendations : 1) 2) 2) It is very practical to use a spreadsheet to record all the measurements. Analyze the measurements on a regular basis for decision making. 3) The ICT Processes Page 11 . It makes it easier to analyze and chart them and analyze their trends. registers. Communicate the purpose behind the measurements. Recommendations and remedial actions that define the actions taken to remedy problem or improvement areas.4) 5) 6) Prepare databases. tables or cards that can be used to register the measurements. Measurements procedures which show how each measurement is to be taken. Remain consistent with measurements. Very often. Changing the nature of the measure over the years stops the Department from analyzing trends and growths. Measurement results : statistics. It is highly recommended to use Statistical Process Control procedures (SPC) that are in common use in Quality Control in the manufacturing sector. Documentation and Deliverables : 1) 2) 3) 4) The Areas of Concern and the individual performance measurements showing the indicators for each. personnel are suspicious of measurements as they might consider such activities as infringing on their behavior.

etc ISO9000 standards Year 2000 standards (Though we are after 31-Dec-1999. Standards may be external standards issued by agencies outside the Department or Government such as the Control Agencies. Implement the standards as part of properly managed projects. other Government agencies are implemented and that the ICT Processes within the Department are compliant with them. PCs for engineers and PCs for management. Many aspects of ICT processes need to conform or comply with some established standard. They may also be internal standards setup by the Department itself. problems still exist) Standards set by Software Development Processes such as documentation forms. Scope of usage : all Information Processes. statutory. database definitions. These may be standards such as the following : Cabling standards : cable speeds. etc. Risks : not complying with standards may result in • • • Legal infringements Inefficient ICT processes Drop in quality Standard Operating Procedure : 1) Identify the standards in question. This Activity provides some Good Practices regarding the compliance with Standards. bending radius. 2) 3) Train the ICT Unit staff so that they can identify the areas of applications and implement and monitor the standards. coding techniques. programming standards.Activity 7 : How to Implement Standards Objectives : ICT goes regularly through phases of confusion followed by standardization. The ICT Processes Page 12 . The benefits of complying with standards are the following : 1) 2) 3) To avoid breaches of any criminal or civil law. maximum lengths. regulatory or contractual obligations and of any security requirements To ensure compliance of systems with organizational policies and standards To ensure that various standards set by the Department’s Management. international bodies. etc Auditing standards set by the various Control Agencies in the Government Arabic software standards Purchasing standards set by Tendering Committees or Donors Etc. For example. International Standards bodies. the Department may issue a standard for PC configurations covering the following : clerical PCs.

4) Monitor and audit compliance as an ongoing activity Documentation and Deliverables : 1) 2) 3) 4) 5) A list of all standards to be complied with Documents that define the standards. It is a good practice to budget for such acquisitions and to constantly revert to the related web sites for information about upgrades and their related costs. getting familiar with a standard during its inception will result in more efficient implementation. Various standards such as the various ISO levels need to be purchased as they are not available in the public domain. 2) The ICT Processes Page 13 . Implementation procedures Tests that verify compliance Results of the tests prepared on a regular basis Good Practices 1) The ICT Unit should be constantly on the lookout for standards that may be emerging. Often.

Activity 8 : How to Manage ICT Projects Objectives : Project Management is an organizational discipline that is becoming more and more accepted as part of ICT life. The following is a list of responsibilities or functions a Project Manager has. This Activity emphasizes the role to be played by Project Management in ICT Projects. Managers without the right experience. irrespective of whether the post is on the side of the Supplier or the Department : • • • • • • • • • • • • • • 2) Reports to Senior Management The Manager is the Primary Driver of the Overall Project completing such activities as : planning. These two persons will work as counterparts jointly assuring the success of the project. specifically that of the Project Manager. execution. Risks : • • • Projects without management will eventually fail. A major area of inefficiency in ICT Units is the lack of proper Project Management. Good Practices and Recommendations : 1) Responsibilities of the Project Manager : it is necessary that the Supplier appoint a fully responsible Project Manager no matter what size or scope the agreement has. Projects without managers will fail in the same manner. Scope of usage : covers all types of ICT Projects whether handled by the Department or by its Suppliers. their budgets nor their deadlines. general Project Management is not very different from ICT Project Management. monitoring and control Coordinates between all parties Manages product scope and specification Manages resource allocation Manages project scheduling Tracks and monitors all Project activities Communicates project status and progress Facilitates team communications and interactions Communicates with project stakeholders Decides on key or critical trade off decisions Analyzes and manages risks Manages change control and configurations Implements Quality Assurance to ensures that the project maintains it Quality Modern Project Management techniques : project Management principles apply to all types of projects. profile and authority will not be able to manage projects properly. The main differences lie in the The ICT Processes Page 14 . It is also critical for the Department to appoint its own Project Manager. Failed projects will not meet their functional promises. Essentially.

especially those that handle software development. pmi. (Review Activity 6 : Setup a Performance). technical issues. ICT Projects require the following additional principles and methods : • • • • The use of business modeling for systems analysis and design The use of standard Software Development Processes (Review Activity 46 : Using a Software Development Process). The content of the following general Project Management processes would be different for ICT although the techniques are be the same : risk management. 4) 5) The ICT Processes Page 15 . The Department should establish standards for Project Management to be applied internally as well as requested from Suppliers.org. configuration management. It is a focal point of modern and standardized project management practices. The Department should establish Performance Measurements and Indicators for its own Projects. quality control. 3) Project Management Software : even if Project Management principles are not learnt with proficiency. ie. It is recommended that the Department look into the possibility of training their own staff in ICT Project Management.management of the scope of the products. costing. it is still highly recommended that the team use a standard Project Management software such as Microsoft Project 2000™. The implementation of team structures is very specific to ICT processes. The latter can be part of the issued Requests for Proposals. One web site to visit is the Project Management Institute’s website : www. (Review Activity 7 : How to Implement Standards).

The Department will have a difficult time updating. 2) 3) 4) 5) The ICT Processes Page 16 . password lists. documentation. this would cover the ICT System hardware. This becomes the Baseline Configuration. Changes will take place in an ad hoc and uncontrolled manner leading to discrepancies. many other elements can be added. Setup all items on the Configuration Database as they are on a specific date. etc. deletions and modifications of items in the Configuration must adhere to the Change Control System defined next. Standard Operating Procedure : This procedure closely follows the detailed processed defined in the Appendix of Supplementary Material of Supplementary Material. mismatches and other problems. network components and software items. the Guide defines the whole Configuration Management Process. Identify and Determine the Configuration elements. Configuration Management controls all components in an ICT System such as software. However. It also implements a change control procedure to control and track all changes to the initial configuration. upgrading or gathering information about the status of the system. network components. Develop a Product Numbering Scheme and Hierarchy Develop other coding schemes that may be used such as tag numbers. Standard Operating Procedure : Preliminary and One Time Tasks 1) Determine which Configuration Management software the Department wishes to use to manage the Configuration. components. This is especially damaging in the case of software systems under development. All subsequent additions. losses. Risks : not launching a Configuration Management process will lead to the following damages : • • • The Department will not know what is included in the ICT Systems which will causes losses. Scope of usage : the scope of the Configuration Management process totally depends on what the Department wishes to include in the Configuration. etc. etc. open the system to pilferage. At the most minimal level. maintain it and benefit from the results of the information it produces. training material. In the Appendix of Supplementary Material of Supplementary Material. media. it can be acquired or developed and made ready for use. hardware. The steps discussed in the Appendix are summarized below. items.Activity 9 : Setup the Configuration Management Process Objectives : to setup a Configuration Management process. etc. Once this is determined.

Standard Operating Procedure : Ongoing Management of the Configuration 1) Use the Change Control System to ensure that any change to the Configuration is subjected to the following process : • • • • • • 2) Define the information needed to prepare a Change Request Request the change Analyze the Request : reason. (Review the Appendix of Supplementary Material of Supplementary Material for a more detailed list of such information). etc. printers. deletion of items or their removal or uninstallation as well as any changes such transferred locations. scanners.6) Develop a Change Control Mechanism. 3) Good Practices 1) What to include in a Configuration? The Configuration can include but not be restricted to the following items (In alphabetic order) : • • • • • • • • • • • • • • • • • • • • • Business Modeling Diagrams Cabling Compilers Databases Design specs DLL’s and ActiveX Components Documentation Hardware components and units (PCs. etc) Screen designs Servers Shell scripts Site units Environment units and test equipment The ICT Processes Page 17 . This will allow the Department to control all additions. clients. Approve or reject the Request (Or request additional information) Implement the Change Record the Change in the Configuration Database Changes such as the following are also subject to the same mechanism : addition of new items to the ICT Systems. costs. etc. modems. Monitor and Track the Configuration through the analysis of the information being processed in the Configuration.) Integrated Development Environments Network components and units Object code components Operating Systems Power components and units Prototypes Queries RDBMS (Servers. impact. upgrades. deletions and modifications of any item on the Configuration. etc. timing.

lists or registers as a means of documenting procedures. there is a constant recommendation to setup minor databases. it is advisable to setup these databases or lists on the Configuration database. If the Department sets up a Configuration Management process. the Appendix of Supplementary Material lists a variety of different analytic reports to be reaped from such an application. The ICT Processes Page 18 . The following are examples of such items : • • • • • • • • • • • • Agreements Agreements with Suppliers Backup media Data sheets submitted by Suppliers for various equipment Items under maintenance agreements List of suppliers List of supplies Project plans System manuals and documentation Training institutions Training material Workshops and courses of such institutions Documentation and Deliverables : Over and above the actual software application to be used for Configuration Management.• • • • • • • • • • • 2) Software Applications Software Tools Source Code Style sheets (CSS) Telecommunications components and units Test Data Test Plans Upgrades and Patches Web Pages XML Schemas Etc Include Minor Databases and Registers : throughout most of the Activities of this Guide.

etc.0 Managing ICT Human Resources Human Resources are one of ICT’s major problems. Job Classifications are faulty and neither reflect the Department’s needs nor the qualifications of the recruits. Staff are not progressively trained.2. The Technology is changing. reruns. The ICT Processes Page 19 . rework. High turnover of staff Demotivated staff Regressing technical knowledge and competence Problems within Project Management due to improper staff responsibility allocations The following sets of Activities provide some Procedures and Good Practices related to ICT Human Resources. These Activities are supported by an extensive section in the Appendix of Supplementary Material regarding the Organization of a typical ICT Unit. All of the above lead to inefficiencies and risks such as : • • • • • • Poor performance in all areas of ICT Errors. generally horizontal in the ICT environment. Responsibilities. are not clearly understood nor efficiently implemented.

The ICT Processes Page 20 . Different organizations operating in different environments have also constantly had to change their structures. 1) 2) Identify all positions in the ICT Unit and the positions they report to. The structure cannot easily be modified as technology changes. The difference between what Management considers their job and what they consider their job can often resolve a lot of issues. These have to be considered as part of the overall structure even though they may not report directly to the ICT Unit Director. The Guide will propose a generic Organizational structure that can be used as the basis for specific Units in each Department.Activity 10 : Organize the Structure of the ICT Unit Objectives : to define the Organizational Structure of the ICT Unit according to modern principles. Scope of usage : the ICT Unit in the Department. some Departments might have small isolated ICT units following major Directorates or Agencies that report to the Ministry. However. Specific responsibilities or functions might be left unaccounted for leading to improper performance. Hence. Standard Operating Procedure : The Guide will use the term “Position” instead of a “Job”. The term position defines a position that is created by the Department for a specific purpose. Risks : an ICT Unit without a properly understood structure is subject to disruptive behavior : • • • • • Overlap in responsibilities will cause tension and errors. It would help to have the persons write down what they assume is their job. Personnel will team up in political or social groups causing damage to the overall work. This position may or may not be filled. Different periods in ICT history have required different types of personnel with different relationships. Such a structure is presented in the Appendix of Supplementary Material of Supplementary Material to avoid disrupting the flow of Activities. Personnel will not be able to view their career path which is demotivating. the Guide will not be able to propose a standard Organization Chart for ICT Units. Use a minor database to setup at least the following data elements for each position : Description Date created Grade / Subgrade Date filled Staff ID Position it reports to Responsibilities (Text) The responsibilities of each person would be as they are doing the work today.

a minor database application or a diagram. not vacant. The ICT Processes Page 21 . link that position to a simple Employee record containing at least the following data elements : Staff ID Name Title Date of birth Date of joining the department Educational level (Linked to multiple records) Work experience (Linked to multiple records) 5) 6) By now. If a position is occupied. Acceptance Criteria : The Organization Chart needs to be approved by the Management of the Department before it becomes official.3) 4) Start by charting the ICT Unit on an “AS IS” basis. This is a Position Classification exercise which is necessary for the other Activities discussed below. ie. Continue by reshuffling responsibilities to fit the new structure for the Department. the Department should have a fully detailed Organization Chart showing which staff is in which position. This would help clarify the responsibilities of each person. Proceed by converting existing titles to industry standard nomenclature as presented in the Appendix of Supplementary Material of Supplementary Material. Such a form can be as simple as a spreadsheet. Documentation and Deliverables : The above Chart can be in a hard copy but it is recommended to have it in an automated form.

Activity 11 : Identify the Required Competencies per Position Objectives : to identify which Competencies are required for each Position in the ICT Unit. Competence is a major issue in ICT. The following example takes a generalized approach by grouping typical Competencies under two groups : Non-Technical PC literacy Managing Teams Project Management Configuration Management Human Resources Development Training Business correspondence Presentation skills Reception work English (Writing Level) Arabic (Writing Level) Etc The ICT Processes Page 22 . Risks : not defining competencies will lead to the following risks : • • • Improper evaluation of staff Inefficient training A poorly defined Organizational Structure Good Practices and Recommendations : 1) 2) 3) Identify Expected or Required Staff Competencies for each Position by listing all experience. knowledge. they can be used in the following areas : • • • • A position can be defined by its required Competencies The staff’s actual Competencies can be identified to assess their fit Training courses can be defined by the Competencies they enhance Competencies can be tested for in staff performance evaluations Scope of usage : the whole Department but specifically. This would identify Competencies that may be required. this could vary from technical to non-technical competencies. Upon defining competencies. Competency is a special ability a staff member acquires through training. Group competencies under some classification in order to analyze them jointly. The Technology changes so fast that staff who are considered experienced this year may be without much experience in a year’s time. the ICT Unit. Within the ICT world. education or experience. education or training that each position should have. Review lists of training courses for ICT personnel.

5) 6) Documentation and Deliverables : A list showing all the Competencies required or expected of the Staff holding such each position in the ICT Unit. Office 2000 capabilities can be defined at beginner. For example. Avoid defining Competencies in a broad manner. Try to have a highly focused definition of each competency. intermediate and advanced levels.Technical Developing in Visual Basic Developing in Java XML NT Server Certification RDBMS Design Autocad Lotus Notes Microsoft Certified Professional (MCP) Microsoft Certified Systems Administrator (MCSA) Microsoft Certified Systems Engineer (MCSE) Microsoft Certified Database Administrator (MCDBA) Microsoft Office User Specialist (MOUS) Etc 4) Within each Competency. The ICT Processes Page 23 . The same may apply to Languages : Spoken. This would disable the Department from evaluating whether a specific person has reached the required performance. Review all new technologies being introduced in the Department to establish whether additional Competencies are to be considered or not. Read or Written levels. it may be useful to define several attainment level. It would also stand in the way of clearly identifying training requirements.

competence and project history of all staff. Standard Operating Procedure : 1) 2) Prepare a list of all Positions in the ICT Unit. the Department can analyze the gap between required and actual competencies therefore identifying training needs. (Review Activity 11 : Identify the Required Competencies per Position). From this analysis. In a later Activity. experience. They may also help the Department drop some Competencies which were wrongly attributed to the staff member. Documentation and Deliverables : A list of all staff currently in the employ of the Department showing the Competencies of each. competence and project history of the ICT staff may lead to improper use of current personnel.Activity 12 : Identify Actual Competency Levels of all Staff Objectives : to analyze the education. the Department would get a list of the Actual Competencies each person has. the ICT Unit. Later on. For each staff member. this would lead to demotivation and reduced performance as well as increase the risk of turnover. analyze the following : • • • • • 3) Training attended within the Department Training attended before joining the Department Experience acquired within the Department Experience acquired before joining the Department Educational qualifications Identify the Competencies each staff member has. If qualified staff are kept in the wrong positions. Risks : • • Not knowing the education. Good Practices and Recommendations : 1) Personal interviews may highlight Competencies that were not identified from the paperwork analysis. experience. The ICT Processes Page 24 . this can be used to compare the staff’s actual competencies with the expected competencies as defined in the previous Activity. This would provide the Department with a solid basis for reaching the following : • • Evaluating the Performance of Staff Planning their Training Scope of usage : the whole Department but specifically. (Review Activity 13 : Analyze Competencies to Identify Training Requirements). poor career path planning and inefficient training.

2) Testing : in some cases. 3) The ICT Processes Page 25 . It is often useful to have staff review their own Competencies and those of other colleagues. it may be useful to test staff to verify that they actually do have a certain Competency and that it has not been forgotten due to lack of experience or time. This would further help the Management with the identification process.

Documentation and Deliverables : A list of all staff and their required Competencies. If wrong training is offered. This can be resorted to show each Competency with a list of the Staff that require it. The ICT Processes Page 26 . Having completed the two previous Activities of Identifying the required competencies per position and Identifying all staff competency levels. 4) The list of all staff and their required competencies can now be sorted by Competency. It identifies the staff member who is short of his or her position’s qualifications and would also define the Competencies needed to make the person fit for that position. the next step would be to analyze the “Balance” or the “Gap” between what Competencies are required and what each staff actually has. Risks : • • • • Lack of proper training leads to reduced performance of the ICT Unit. Standard Operating Procedure : 1) Complete the Activities discussed in the previous two Activities. Gap Analysis may result in the following cases : • • • • The The The The staff staff staff staff may be over-qualified for the position may be under-qualified for the position but untrainable fits the position he or she is in very well may be under-qualified for the position but trainable 2) 3) The first two situations have to be dealt with by the Department’s management. Scope of usage : the whole Department but specifically. Compare the two lists and identify the “Gap” or the Competencies needed by each staff member to be fit for the position that he or she is occupying. These should produce a list of all required Competencies per position and a list of all Staff along with their actual Competencies. the ICT Unit. Good Practices and Recommendations : 1) Such an exercise should be repeated at least once a year. planned and completed. The last situation is what is being sought in this Activity. this may lead to the same damage Wrong training will also lead to wasted costs If staff are trained and not kept satisfied. approved. they would leave the Department either to another employ or would request to be transferred.Activity 13 : Analyze Competencies to Identify Training Requirements Objectives : to identify the training requirements of staff so that the training can be budgeted for. This allows the Department to plan the training for all staff.

2) Such an exercise should strongly be tied in with Performance Evaluation practices. should be informed that such a Competency will be tested during the next Performance Evaluation. 3) The ICT Processes Page 27 . It is usual to have yearly evaluations. the Department would test whether the particular Competencies had been acquired or not. etc. can be acquired at the personal level and not through training). (Examples such as language proficiency. communications skills. It is important that a person whose Competency is to be acquired through his or her own effort and not through training. During each Performance Evaluation.

Good Practices and Recommendations : 1) 2) The Department should have cost estimates for most of the training being investigated. attending such exhibitions is always educational and would provide the staff with exposure to new technologies and products as well as present them with the chance to collect data sheets. 3) The ICT Processes Page 28 . attend lectures and discussions. With the advent of the Internet. contacts. Correspond with institutes to keep the Department up to date. It can then be shared by setting it up on the web. Risks : not having lists that are up to date will lead to loss of time when training is required. Maintain a table of website links that offer free or chargeable online training.Activity 14 : Identify Training Resources Objectives : to setup and maintain a register of available training. type of workshops. There are many institutes offering training courses. However. workshops and programs in the field of ICT. These do not represent formal training. Technical exhibitions and forums can be of major benefit. Such information collected by various ICT Units in the government should be consolidated. Secondly. not knowing what is available in terms of training may lead to misconceptions about what the staff may require in terms of their training. List key training areas offered by each institute Relate each training area to specific Competencies identified earlier. etc. Standard Operating Procedure : 1) 2) 3) 4) 5) List all institutes that offer training with data about them : location. many sites also offer free or chargeable online training.

The ICT Processes Page 29 . Different persons will attend different workshops or courses and bring back training material with them. tutorials. etc. Scope of usage : all the Department including the ICT Unit.Activity 15 : Manage Training Material Objectives : this Activity presents some Good Practices that aim at maintaining a list of all training material : documents. (Review Activity 9 : Setup the Configuration Management Process) Share such registers or lists via the internal site of the Department or through regular announcements or inter office memorandums. Invariably. Such material can also be included in the Configuration Management database. Good Practices and Recommendations : 1) 2) 3) Prepare a register of all such training material. such material gets spread around the Department and will not be shared resulting in lost resources. CDs. web sites.

instructors and attendants Costing analysis Scope of usage : all the Department including the ICT Unit. Training control systems have wide functions.Activity 16 : Maintain Training Records Objectives : to setup and maintain a Training Control Database. etc) Records of the actual results with evaluations of courses. The main purpose would be to plan training. The ICT Processes Page 30 . However. However. it can be a simple matter to maintain a set of Training records for the ICT Unit staff. the design is not very complex and can be easily developed into a minor database. The application would cover the following functions by setting up the following records : Staff members Training institutes or training resources Available workshops/courses Required Competencies Actual Staff Competencies Planned training (Workshops. courses. assign courses to staff and track the results of training per person and per institute or instructor. Suggested Approach The Department can acquire such a system commercially.

This Activity suggests a way to automate the Recruitment process. 7) 8) 9) The ICT Processes Page 31 . Many applicants skip over jobs they had problems with. Gaps should be checked. It should be a simple matter to setup a basic database of all CVs received. On receiving applications. Risks : if such practices are not implemented. Scope of usage : all personnel including ICT staff. the Department risks the following : • • Accepting staff with the wrong or fraudulent credentials Insufficient knowledge about the recruit may result in accepting staff for the wrong positions Good Practices and Recommendations : 1) 2) 3) 4) 5) 6) Irrespective of the title being advertised. This practice is not efficient as an employee is not only recruited for his or her technical knowledge. Projects in the order of one or two weeks should normally be sufficient to verify the competencies of the new recruit. Multiple interviewing should take place either through panel interviewing or through a series of interviews with different persons. Some applicants glorify the work they did at specific jobs. it is important to check work references. Experts in related areas such as the unit that will benefit from ICT Services or the Financial Unit or Human Resources should also be part of the interviewing process. It also recommends the maintenance of an applications register that allows the Department to review its applicants and follow up on their recruitment. It is usually the case that ICT staff only get checked by ICT experts. it is best to include in the clear job definitions to avoid receiving more applications than needed.Activity 17 : Define Recruitment Standards Objectives : to standardize recruitment practices and get the best out of recruitment of staff. On recruiting a person. track and control the applications received by the Department. the Department may already have applications that they need on such a database thus avoiding time loss and additional advertising costs. Review the Appendix of Supplementary Material for a presentation on the setup of an applications register to help monitor. it should be easy to find a short term project that the person can complete as a test of his or her capabilities. Very often. Educational qualifications should also be checked.

networking. The ICT Processes Page 32 .3. development tools. tailored. office technology. so that in a proper ICT environment. database engines. It is important to recognize the Activities in these Sections as being recommendations and guidelines and that in no way will the recommended Procedures and Good Practices replace official procurement policies but should be supplementary to them. Proviso This ICT Process in this Section as well as those in the next Section on the various Qualifications are closely related to Procurement Policies that the Government and/or the Department may already have in place. The relationship with Suppliers needs to be Quality Controlled. off the shelf applications. suppliers become a major part of the ICT Processes supplying the Department with such a variety of products and services as the following : • • • • • • • • • • Hardware Networking components Telecommunications Services Web based services Software of all types : operating. etc Training Support and maintenance Recruitment Secondment of staff Etc Some of the above products and services may be internally supplied. it may be necessary to apply the same Good Practices to Suppliers as to the internal sources.0 Relationships with Suppliers Due to the wide variety of products and services needed by ICT Processes.

The lack of history tracking may cause the Department to purchase products and services from suppliers that it had had a problem with in the past Standard Operating Procedure : 1) 2) 3) Identify the major areas of Products and Services that the Department is interested in. The ICT Processes Page 33 . software. The database can have the following functions : • • • • • A record for each supplier A list of all products and services per supplier A list of the history of the Department’s transactions with the supplier The profile of the supplier : experience. prices and general quality. etc The team in the supplier’s company that may be of use to the Department Documentation and Deliverables : The database setup above that can produce lists of Suppliers or lists of products and services. Furthermore. However. Risks : should the Department not have such a list : • • It would take a longer time to arrive at the right choice of products and services in the market. After such a selection.Activity 18 : Prepare a List of Supplier Products and Services Objectives : to setup a list of Suppliers with their offered products and services. Scope of usage : the Department can expand this Activity to cover all products and services that it is interested in. Setup a minor database that contains a record for each Supplier. This can be used to speed up search and cataloging. Prepare a multilevel classification of such Products and Services. typical projects. This Activity does not replace that of Supplier Qualification or Audit presented in the next Activity. the Activity will address ICT services and products. this list can be used to maintain a history of the relationship with the supplier evaluating their performance. Setting up a list of Suppliers on a minor database will allow the Department to easily locate suppliers by product or by service. Suppliers that only sold one type of product can now sell hardware. Suppliers are no more specialized as they were in the 80s and 90s. web services and consulting. Supplier Qualification may take place. It compliments it by providing the Department with a wider list of products and services to select Suppliers from.

This would ensure that Suppliers improve their products and services. Currently. It is important to coordinate with other Departments to avoid duplicated effort as other Departments would have most likely gone through a similar exercise. Furthermore. some general and some directly focused on ICT products and services. there are several companies promoting business directories. the experiences with different Suppliers may then be shared. 3) Consult various directories to update the database. it would be useful to include such information on the Database. The ICT Processes Page 34 .Good Practices and Recommendations : 1) 2) As there would be many suppliers promoted on the web.

The Department needs to establish the different types or level of relationships it requires from Suppliers. location. Scope of usage : mostly applied to Suppliers with whom the Department enters into a Commercial Agreement. the Quality of the supply process becomes a critical issue to the Department. the Department requires a minimum of 3 and a maximum of 6 Suppliers to form a Short List. These are some of the usual levels of relationships : • • • • 3) Long Lists of Suppliers that are suitable in general terms Short Lists of Suppliers that are more focused on specific projects Final Supplier Qualifications where selected Suppliers are subjected to very strict procedures of Qualifications in a specific project. All of these have to be taken into consideration when Qualifying Suppliers (Or sources). Prequalified Suppliers that have been subjected to formal procedures of Qualification and are found suitable in general terms. Define the Type of Relationship Required : such relationships between the Supplier and the Department may be ongoing or may be defined on a one time or a project specific basis. here is a typical definition of a Short List relationship : “For the Supply of Office Technology Products Training. history. key personnel. For example. This is not to be confused with some very strict and disciplined procedures for “Prequalifying” Suppliers which may be project specific. However. This Activity presents a single process that allows the Department to qualify whether it wishes to acquire products and services from this Supplier in the future or not. This was discussed in the previous Activity 18 : Prepare a List of Supplier Products and Services. Standard Operating Procedure : 1) Supplier Lists : prepare lists of Suppliers classified by type of service or product. 2) Each of the above relationships should have its own Qualification Procedures. It is a Good Practice to setup an efficient database that sets up other data about Suppliers such as size. This Activity prepares the Department with some Good Practices that result in Qualifying Suppliers. the Department may end up dealing with Suppliers that are of lower quality than it expects. Risks : should the Department not have a Supplier Qualification procedure. etc.Activity 19 : How to Audit or Qualify Suppliers Objectives : with such a wide variety of suppliers in the market. These Suppliers should be evaluated with the following criteria so that any Supplier not scoring above 70% would be dropped from the evaluation and the Department will then select the Suppliers with the top 6 scores : The ICT Processes Page 35 . it may often arise that the Department can be the beneficiary of products and services from International or Local Donors. It also often happens that the Department may acquire products and services from other Departments.

Example : Long List Relationship : since this is a general list for use while prospecting for Suppliers. Therefore. documented evidence. the Department would find it necessary to expand the evaluation scale and use percentages. etc. No) (Good. Therefore. (Review the Appendix of Supplementary Material where a detailed presentation is given of the Weighted Index Scoring Procedure). Bad) (Yes. The Department needs to define very clear and easy to test Evaluation criteria that allow the Department to accumulate scores for each of the factors it wishes to use while Qualifying a Supplier. Bad) (Good. 4) Evaluation Criteria are the heart of Supplier Qualification. rigorous testing may not be possible. Medium. 5) Qualifying Methods : depending on the nature of the project and the relationship that the Department is going into with the Supplier. Therefore. site visits. They would require to have more rigorous testing such as sample work. In all above tests. Supplier Qualification will not be Quality Controlled. This procedure allows the analyst to normalize and convert such criteria into one evaluation score. it may use one or more of the following Qualifying Methods : • • • • • • Documented evidence Certified evidence Letters expressing interest in joining projects Proposals Company profiles / brochures Company presentations (Yes. Medium. the Department should use the Weighed Indexing Scoring Method to arrive at its results. the Department may find it simple and efficient to use 3 point scales for such evaluations as the following : Relevant experience Team Profile References Age of Company Prior dealing with the Department Compliance Level (ISO9000) Etc. etc) Financial standing Etc. BSI. (Weights will then total 100%) Example : Short List Relationship : a Short List will usually result in a set of Suppliers invited to bid on a specific project. short lists are more demanding. Medium.Relevant experience in general and for the specific project Team profile References Age of company Prior dealing with the Department Compliance levels (ISO. Medium. Maybe. Without clear evaluation criteria. young) (Good. No) 15% 15% 15% 10% 10% 30% The ICT Processes Page 36 . DIN. Bad) (Old.

especially if it is web based. all Supplier evaluations must be documented and approved by the Evaluation Committee. Quality Assurance Methods at the Supplier’s : department should investigate any quality assurance programs used by the Supplier. Compliance with International Standards : in some situations. it would be Good Practice to setup a database for each Supplier and then setup a record for each time the Supplier was subjected to a specific Qualification Exercise.• • • • • • • • • • • 6) Product data sheets Product specifications Site visits Product demonstrations Response to questionnaires and specific surveys Interviews with key personnel Reference checking Qualifications checking Educational checking Compliance certification Evaluation of specific processes (Software development. This would also make it easier for the Suppliers to keep their data elements up to date. the whole Government should be able to share such information. training schemes. 2) 3) Documentation and Deliverables : 1) 2) 3) Supplier Lists Evaluation Criteria Qualification Results Generally. The Department should identify such standards and request the Supplier to confirm compliance with them. In the future. The ICT Processes Page 37 . future Supplier Qualification exercises may benefit from the results of earlier findings. their programming standards. implementation methodologies and their documentation reviews. Good Practices and Recommendations 1) Coordinate with other Departments who may have already carried out the exercise of preparing such lists. Such documentation may be recalled in case of disputes or contestation. the Department would expect the Supplier to comply with specific International Standards such as the various ISO standards. etc) Documenting Qualifications : having established the Evaluation Criteria in very clear terms. Software Development Processes (SDP). Furthermore. installation procedures.

there will be cases where agreements lapse for a short period or when agreements expire but the information they contain is of historical or auditing value to the Department. this Activity is concerned with current Agreements. On a regular basis. The ICT Processes Page 38 . a Consultant might be assisting the Department in one project only to find out that the same Consultant is bidding for a Software Development project with the Department. expiry. Such a register would also allow the Department to analyze possible cases of conflicts of interest. the following might take place : • • • Agreements might lapse giving the Supplier the chance to change his terms with the Department. expiry and payment schedules. For example. The following types are some of the agreements this Activity covers : • • • • • Purchase agreements Maintenance and support Training Consulting services Secondment Risks : should a list of agreements not be available. date. These two types should also be included in the list. reference. The purpose would be to consolidate the location of such agreements. However. schedules Renewal terms Physical location of agreement document (Or file number) Brief description of agreement Main items to be delivered Financial terms Update the database on a regular basis as and when agreement elements change. Standard Operating Procedure : 1) 2) Identify all agreements with the Department Setup a minor database that houses such data elements as : • • • • • • • 3) 4) Agreement data : supplier. analyze the database to list all agreements that are about to expire during the next month or two. scope of work.Activity 20 : Prepare an Agreements Register Objectives : to prepare a list of all current agreements between the Department and any outsourced services. Scope of usage : generally. monitor and track their performance as well as their other terms such as renewal. etc Scope of agreement : deliverables. Conflict of interest may arise. Payment schedules may be missed.

Good Practices and Recommendations : 1) 2) Setup the agreements on the Configuration Management database Link the agreements database with the Supplier database discussed in Activity 18 : Prepare a List of Supplier Products and Services. The ICT Processes Page 39 .Documentation and Deliverables : List of all agreements with minimal data elements.

It can also be used for internal purposes such as Performance Evaluation of staff. alternatives the Weighted Index Scoring procedure can be used. Scope of usage : whenever the Department wishes to evaluate Suppliers. Products. Offers.Activity 21 : Evaluation of Suppliers. Projects or Alternatives Objectives : this Activity presents a summarized procedure on how to compute Weighted Indices that combine various evaluation criteria into one number or index. When evaluation criteria of proposals are not clear. Risks : without proper evaluation. Products. The following are examples of Evaluation Criteria that are mixed in that they apply to different Information products and services : Reliability Technical fit with the Department’s requirements Profile of the team Profile of the company Relevant experience Knowledge of the business domain of the Department Timing Price Offered features Responsiveness to RFP (Have they understood what was requested) Project Planning Additional features 3) Assign weights to such criteria. the following risks may arise : • • • Suppliers may contest the selection process The selection process may result in unsuitable choices being made Suppliers may bias their proposals on false assumptions being made by them as to what is “important” to the Department Standard Operating Procedure : 1) 2) Select the factors that best reflect the criteria that are important to the Department and make them the Evaluation Criteria for the offer. A more elaborate and detailed discussion of the Weighted Index Scoring Procedure is available in the Appendix of Supplementary Material. Suppliers will unbalance their offers to ensure that get selected. projects. Examples : Typical Government Tender on best price Price Equipment RFP on price and features Fits with Requirements Price 30% 70% 100% The ICT Processes Page 40 . etc.

Consultancy Services Price Company Profile Team’s Profile Responsiveness to RFP Relevant Experience 30% 15% 20% 10% 25%

Of course, any of the above criteria can be broken down further such as the Experience in the last example : Relevant Experience Technical fit Business domain fit Project management 4) 25% can be broken down into : 10% 10% 5%

Identify any pass/fail criteria. For example : “Companies that do not get 70% on their technical score will not be considered in the overall selection”.

5) 6)

Publish the evaluation scheme in full detail in the Request for Proposal so that Suppliers can prepare their proposals according to the defined weights. On receiving the proposals, each offer needs to be evaluated and scores given to each criterion. The best score would be computed using the Weighted Index Scoring Procedure defined in the Appendix of Supplementary Material.

Documentation or Deliverables : 1) 2) 3) The full evaluation scheme : the criteria, the range of scores, the weights and any pass or fail conditions. A list of all items to be evaluated with all their scores The computation of the Weighted Index Score for each item

Acceptance Criteria : when the best item is selected according to the Weighted Index Scoring procedure, the Activity is accepted.

The ICT Processes

Page 41

Activity 22 : Recommended Issues to Consider in ICT Agreements Objectives : many attempts have been made to develop Standard Agreements betwee customers and suppliers. Due to the changing nature of technology, the different circumstances surrounding each agreement and the various policies and strategies followed in different Departments, it becomes very difficult to develop such Standards. This is a fairly long Activity. It discusses a variety of problematic issues that may arise while preparing Agreements and proposes solutions to such issues. Scope of usage : the typical Agreements that will be considered are the following : • • • • • Purchase Agreements Requests for Proposal Support Agreements Maintenance Agreements Warranties

Risks : poorly developed agreements may never be a risk until disputes take place. In all cases, whether it wins or not, the Department would be the loser. It is the Department’s objective not to have to fall back on Agreements and litigate. Therefore, the major risks of these Activities are : • • • • • Lack of agreements Poorly written agreements Agreements based on Supplier Proposals Agreements that over-pressure the Supplier leading to eventual poverty in delivery and performance Agreements that do not address the issues discussed in the next few subsections

Specific Activities will have their own Risks and will be discussed in what follows. 3.1 Including Technical Specifications in Agreements

In Section 4.0, the Guide presents a set of Qualifications, starting with the Specifications Qualification (Review Activity 23 : Specification Qualification (SQ) and Activity 1 : Define Business Objectives as Related to ICT). These two Activities provided SOPs that ensure that proper designs have been made and that Specifications to be used as the basis of delivery are in place. The Guide will not expand on this issue in this Section. 3.2 Schedule and Timing of Product Deliveries

After the Technical Specifications, the second most important element in any project is the Schedule and Timing of activities. Many Agreements present a broad listing of target dates and delivery times. What is missing are some of the the following crucial dates : • • • Detailed start and end dates of each activity in the project Identification of key milestones Identification of Delivery and Acceptance periods and expiries

The ICT Processes

Page 42

• •

Identification of Warranty period starts and ends Identification of points when payments are to be issued

Also missing are the following elements related to timing : • • • • Sequencing of Project activities Contingency planning in case there are delays in the activities Manning or the effort required to complete the activites needed to evaluate the reality of scheduling Assignment of Project personnel to individual activities

Here is a broad procedure for preparing the timing : 1) 2) 3) The Department usually starts by defining a broad and general timing. This would be based on key milestones in the project. The Supplier will then analyze the Products and Services being proposed. Based on such analysis, the Supplier will then prepare a rigorous timing plan that contains all activities, their duration and their sequencing.

In the Request for Proposal issued by the Department, it is highly recommended to request the Supplier to submit a Project Plan, including all the above elements, in an industry standard Project Planning Software product such as Microsoft Project 2000™. 3.3 Costing and Other Financial Issues

Usually, most agreements are overly concerned with financial issues. However, there are various weaknesses to be avoided. 1) Internally, the Department should rigorously estimate the overall cost of the products and services being requested. Poor estimates result in the following risks : • • • • 2) Proposals may result in wild variations leading to project cancelation. This causes time loss and is unfair practice on the Suppliers. Suppliers may have prior knowledge of these poor estimates and may gear their proposals according to them. This would result in poor deliverables being proposed. Poor estimates may result in unrealistic scheduling of the Project. Estimates that result in larger than budget figures may cause the project to be unnecessarily cancelled.

Payments should be related to specific deliverables that have a very clear Delivery and Acceptance Procedures. (Review the discussions in Section 4.0 : Qualification Processes) Gear payments to the actual work or deliverables by the Supplier. Suppliers often suffer because the schedule of payments does not reflect the work or deliverables


The ICT Processes

Page 43

There are two perspectives to this problem : The Supplier’s Argument : the supplier may have spent a lot of effort to setup standard interfaces. reusable routines. there is a risk of the software not being maintainable or supportable. an escalation factor must be specified that the supplier of such services must adhere to so that coming costs are not increased by more than the said factor.5 Source code is always an issue in Software Contracts. The Department should clearly cater for this situation : who is to redevelop the software. This puts a strain on their cash flow which will only reflect itself on poorer performance and corner cutting. clever solutions of problems. The ICT Processes Page 44 . Secondly. 4) 5) Exchange Rates : clarify currencies in which payments are to be made and what happens on the dates of payment should the rates differ. Upgrades or updates may also require the updating of source code in developed applications. Otherwise. The Supply of Source Code 2) 3) 4) 3. It is critical in an agreement to specify the duration during which the Supplier is obliged to provide such upgrades and updates. Upgrades or updates may require conversion of databases or some rework on the data. with the Source Code in their hands. It should be clearly spelt out in the Agreement as to who is responsible for such conversions. The Department’s Perspective : without Source Code. components. Suppliers are usually reluctant to expose such practices. In such cases. at which cost and how long that would take.4 Software often goes through different releases and versions resulting in major upgrades or minor updates. Software Upgrades and Updates 6) 3. If that is not possible. Escalation Factors : costs must be projected over the coming years. Suppliers ensure continued maintenance and support agreements. 1) Agreements should clearly specify whether the Supplier is responsible for supplying such upgrades and updates and at what cost. the Supplier would be under no obligation to provide the Department with such upgrades / updates. the Department is exposed to the risk of the Supplier going out of business or being acquired by other companies.being submitted by them. Fixing Floats : The pricing of future products can be fixed by relating it to a percent float above an international price list or any other basis that is mutually agreed upon.

In the case where the Department is only interested in accessing the data as it pleases. software companies do not have sufficient documentation within their source code making it even more difficult to support by parties that were not part of the development process from the start. The application responsibility becomes that of the Department. This might result in data inconsistencies and erroneous reporting. there are clarifications and solutions to the stalemate that often arises regarding source code custody : 1) It is cheaper for Suppliers to maintain and support software than it is for a Department to learn and train its development staff to support the software. 2) 3. The ICT Unit can then use various Report Generators or even develop software to access its own data analysis and report production. The ICT Processes Page 45 . Inexperienced users may strain the system by devising queries that place major loads on the system. On acquiring the source code.5.5.Secondly. However. such a procedure also has its risks : • • Without proper documentation and training. Under specific conditions. Both these views seem reasonable. 2) 3) 3. However.2 Data Structure vs Source Code There is often confusion in the mind of ICT Units between Source Code and access to data. Departments often feel that Suppliers hold them hostage because Suppliers have the Source Code. such as bankruptcy or stoppage of work. most Suppliers would renounce their obligation to support the application. users may not have a clear idea of what the various data elements mean and how the data is structured within the database. In most cases. It is usual to state in such agreements that the Source Code is only to be used for internal support of the Department’s application and that it cannot be used by other parties nor divulged to them. problems can be avoided by the Supplier providing the Department with a clear definition of the Database Structures. the Source Code can be made available to the Department.1 Suggested Solutions It is recommended that the Department avoid problems related to support stoppage through the following suggestions : 1) The Source Code should be made accessible in the case of bankruptcy or acquisition of the Supplier by other interests not obliged to continue with its support. Agreements can state that the Source Code be placed in escrow with a Bank.

(Review Section 3. Performance issues : generally. The Supplier would have to supply it. 3. 2) 3. some printers are not to operate continuously for more than a specified number of hours). errors are undisputable discrepancies such as : Wrong totals or computations Misalignments Actions that promise a result and do not perform it (Buttons. here are the services generally provided as part of the Warranties and Maintenance of Software items : 1) Correction of errors : the term “Error” should be clearly defined.6. Generally.1 Warranties and Maintenance on Equipment 1) The Department must have the Supplier clearly spell out what parts of the equipment can be replaced free of charge. The issue of Performance is discussed in Activity 26 : Performance Qualification (PQ). performance is difficult to specify. Upgrades and updates are often included as part of Warranty and Maintenance services. Invariably.6 Maintenance and Warranty Services In some cases. data structure and its issues should be separated from the issue of Source Code. etc) Crashes or application hangs Misleading error messages All spelling mistakes and typographic errors Improper sequencing of work (Links that send you to the wrong place) 2) Supply of missing functions : should any function defined in the Technical Specifications not be available in the delivered software. then this may be subject to Maintenance terms. there are accepted rules of thumb as well as clear technical specifications.In all cases. Duty cycles should be observed and defined. (For example. parts that are fixed and subject to failure would be while consumables or items that are under heavy usage such as print heads are not cover by warranties.2 Warranties and Maintenance on Software Generally. menus. However. one does find a small line of print that limits the usage of a specific product to so many hours of non-stop work. Generally.6. 3) 4) The ICT Processes Page 46 . 3. the services offered in each are different. In others. Maintenance is a continuation of the Warranty.4 for some restrictions on such upgrades and updates).

re-installing software.3 Terms Applying to Both Hardware and Software 1) Specify clearly when the Supplier can be called. etc. modifications and enhancements Secondment of personnel during critical periods such as end of month. closings. Calls should be responded to by a visit within 8 working hours from the time the call was placed.7 Many agreements confuse support with maintenance and often combine the two. Specify clearly how long a Supplier can take before responding to the first call. This eventually leads to disputes. then the Supplier has to replace the component with a working one or change the unit at no additional charge. trouble shooting. 2) 3) 4) An example for hardware maintenance would help : • • • • • Maintenance Hours : 8:00 till 14:00 Calls made after 14:00 will be charged at an agreed upon rate. Specify clearly what contingency plan the Supplier has if the problem cannot be solved. force Majeure. etc. Having taken the first call. Support Agreements 3. It is the responsibility of the Supplier. Should the problem not be resolved within 16 hours from the response. Any problem should be resolved within 16 working hours (2 days) of the response. a business shift is specified so that calls outside it are either not answered or are chargeable at different rates. Usually. Support includes such effort as : • • • • • • Additional training Resolving problems which are outside the control of the Supplier such as breakdowns due to damages. Maintenance aims at retaining the system in the working state which it was supposed to have been delivered in. power failures. specify clearly how long a Supplier can take before resolving the problem.6. Support is any additional effort the Supplier has to put to support the Department. the following guidelines are suggested : The ICT Processes Page 47 .3. etc Undertaking activities that are outside any agreed upon work such as upgrades. end of year. Assisting users in activities which are outside maintenance Developing minor reports. migration. Since Support is labor intensive.

8 Schemes should be established to ensure that the Suppliers guarantee continuity of services in terms of supplying maintenance. the Agreement should also specify as to how long the Supplier is under an obligation to provide such Upgrades. Failure to do so should result in compensation by the Supplier or change of equipment. Software upgrades : as per the earlier paragraph on Software Upgrades and Updates. Only those officially requested and approved are included in the statement.1) 2) 3) 4) An estimate can be made of the time that needed from the Supplier in terms of support hours per year. When possible. the Supplier will generally offer them at a lower rate.9 This is one of the most serious areas of disputes between Suppliers and their customers. products are often withdrawn from the market after a few years and spare parts get into short supply. Spare Parts : with changing technology. The total is then booked at an agreed upon rate. On a monthly basis. Generally. Should these hours not be used. the Department will request it and document such requests. The main reason is the lack of an agreement on how such Deliveries are to be made and what constitutes Acceptance Criteria. Delivery and Acceptance Criteria 2) 3) 3. support. the Supplier will still get compensated because of the commitment he made. new products. a rate for additional hours will be agreed upon and used as part of the agreement. Ensuring Continuity of Services 5) 6) 7) 3. spares. Penalties should be included in case the Supplier defaults on this condition. The Department should estimate the life cycle of the products it is acquiring and ensure that spare parts are made available by the Supplier during that period. the Supplier will submit a statement of all hours used so far. Should the Department use more than the agreed upon hours. The Department will need to approve such estimates before they can be executed. the Supplier will provide estimates of specific support work to be carried out. Here are some recommendations : 1) Duration of service : the agreement should include a commitment by the Supplier to maintain his products up to a specified number of years. it should be lower than the yearly rate. Whenever support is needed. The ICT Processes Page 48 . Because such effort is to be booked in advanced.

(Review Activity 2 : Initiate and Plan the Good Practices Project where the Guide discusses the importance of Project Management and the role of the Project Manager). payment terms are tied to certified deliveries which in this case would be postponed. the Department will need the original media which are not available.10 Authorization of Staff Suppliers often deliver goods without there being a recognized party that has the final authorization in certifying that the goods have been properly received.Review Activity 24 : Installation Qualification (IQ) and Activity 25 : Operational Qualification (OQ) for a detailed procedure for Delivery and Acceptance. it is important to have a written authorization for such persons. Therefore. In the case where such persons are to be changed.11 Copyrights and Intellectual Property Various problems arise when Suppliers supply systems with software that is not legally licenses for that system. state clearly which party is responsible for : • • • • 2) 3) Delivering it Installing it Ensuring that it is operational Certifying that it has been properly received as per agreement In critical situations. This will lead to disputes because invariably. 3. This often happens with built in databases or software that is inadvertently left on the installed systems. Risks : • • • Such installed software may be incompletely installed or may require modification to the installed components. documented notices should be issued by the Project Manager. It is important to ascertain that persons expected to carry out key work in a project or an agreement are authorized to do so. This is applicable on both the staff within the Department and those carrying out the various activities in the agreement. at some time. It may not be possible to upgrade such software free of charge or at nominal costs because it is not legally registered. 3. 1) For each deliverable. No support on such software The ICT Processes Page 49 .

2) 3) 4) 5) The ICT Processes Page 50 . Investigate carefully the End User License Agreement (EULA) for the software. The usage of such software beyond specified time limits becomes illegal. Note that “Shareware” is not equivalent to legally licensed software. Using the software beyond the expiry of the current registration is not illegal but will not avail the Department with the benefits of upgrades. Always register the acquired software. This will make available to the Department upgrades.Good Practices and Recommendations : 1) Illegally installed software is theft. support and announcements. Some software may only be licensed on specific number of machines or may be restricted from usage in specific environment. new announcements and support. Some software requires upgrades in registration to maintain it in a valid form. make sure that a license document for each item of software acquired is submitted with the software. To ensure that the Department stays on the right side of the law. patches.

externally or internally.4. installation and use of software applications Design of hardware configurations : networks. The Specifications Qualification has the objective of ensuring that the Technical Design will result in a product or a service that complies with the Requirements of the Users. The ICT Processes Page 51 . etc. Consultancy services : design. Qualification processes are usually required during any of the following processes : • • • • • • • Development. supervision. etc Training Whichever of the above processes is being implemented. the Department needs to go through 4 types of Qualifications as in the following diagram. Specifications produced by the Designers must be qualified. Implementation of telecommunications networks Development of web based applications Preparation of computer sites along with all environmental equipment and testers. 1 Analysis and Design Specification Qualification SQ achieved during Design of Product 2 Development or Construction SDP or Technical Processes Qualifications performed by Business Analysts / Designers 3 Installation Installation Qualification IQ Performed by Quality Assurance Staff Operational Qualification PQ Performed by Quality Assurance Staff 4 Use Performance Qualification IQ Performed by Quality Assurance Staff 1) Analysis and Design : during that phase of the overall delivery process. minicomputer systems.0 Qualification Processes A Qualification is a condition or standard that must be complied with. project management. even if these are internal Suppliers. Qualifications are critical because they are the basis of Agreements between the Department and its Suppliers.

speed. ie. Performance Qualification is carried out to ensure that the products are performing within their expected performance ranges. The Development phase will requires ongoing qualifications. However. operate properly and are ready for use by the User (And for the next qualification). This normally includes response time. Installation covers two major Qualifications : Installation Qualification aims at ensuring that the products have been properly installed and are ready for operation. etc.2) Development or Construction : in software projects. Operational Qualification aims at ensuring that the products. capacity. The above four Qualifications are presented in the next few Activities. once installed. there are various checkpoints and milestones that qualify whether the designs are being properly developed. the term “Construction” is being used to cover the phase in all projects where the deliverables are being “built”. For example. throughput. The ICT Processes Page 52 . Installation : starts with delivery. Such technical processes will not be discussed in the Guide. Increasingly. Within that process. they have passed the Operational Qualification. goes through the installation of the products and ends with the operation of the systems. the term “Development” is used. these are usually technical and follow the technical processes being used. the Department may select to use Microsoft’s Solution Framework Software Development Process. 3) 4) Use : once the systems or the products are ready for use.

etc Training This Activity covers a variety of situations : The ICT Processes Page 53 . These are technical Specifications and can be verified by a Specifications Qualification. The objective of this Activity is to provide an SOP for the Qualification of a wide variety of Specifications (SQ). Definition : the SQ is a technical.Activity 23 : Specification Qualification (SQ) Objectives : the purpose of Specification Qualification is to show that the controls required to specify the design have been addressed and agreed upon by an authorized party. installation and use of software applications Design of hardware configurations : networks. whether there is an RS-232 connection and related software to use on the connected PC or not. Example : a UPS has Specifications such as power capacity. Such risks result from any of the following : • • • • Not having Technical Specifications Improper specifications or those that have not been properly qualified or validated Specifications prepared by persons without the proper and related experience Specifications based on proposals or verbal definitions Scope of usage : all system processes listed at the beginning of this Section : • • • • • • • Development. etc. the SQ becomes the basis of Delivery and Acceptance of the product or service and hence the heart of any Commercial or Internal Agreement. Projects would develop disputes. inappropriate deliveries and deliverables that do not meet user needs. number of output connectors. supervision. battery capacity in amperehours. Once developed. Other issues to be raised in the Specification relate to how the UPS operates : • • • • • What happens when the power goes down? What happens when the power resumes? How do we charge the unit on first use or after stoppages? How do we turn off the alarms? How do we run the software on the PC so that it can shut down the operating system with impending power drops? Risks : the importance of the proper Specification of systems cannot be underestimated. whether there is an alarm when power is down or unstable. quality and commercial review of any product or service that the Department is interested in acquiring externally or developing internally. Consultancy services : design. The lack of proper specifications is one of the major causes of failed ICT projects. minicomputer systems. project management. etc. Implementation of telecommunications networks Development of web based applications Preparation of computer sites along with all environmental equipment and testers.

the Department may have a standard for drawing the network topography may be used.This is particularly critical for software applications. This is a critical step as it is such standards that will be used when evaluating the design in this SOP. Review Specifications : the team setup to evaluate the specifications will now review the specifications and establish whether or not they consist of a complete 5) The ICT Processes Page 54 . The party should be given the authority to approve such a design. such documents must be included in the RFP as an appendix. Establish Standards : define ahead of time what standards are required to ensure that a specific function or feature is properly specified. Such documents as the following may be needed : • • • • • • • • • User requirements specification Functional specification (if available at this time) Supplier qualification or Audit Report Any related agreements Any purchasing standards Technical drawings Data sheets for equipment Catalogs Etc 2) In the case of including the design in an RFP. The users must then analyze all documentation and approve it. Standard Operating Procedure : The following procedure applies to all the above cases : 1) Identify the party that will approve the design specifications. 3) Collect Required Documents : identify and collect the documentation that the Design would be based on. Example : while developing software specifications. 4) Involve Users : ensure that the staff who will be the direct beneficiaries and users of the deliverables are part of the planning process that defines what is to be designed. This may be a single user or a Technical Evaluation Committee. Example : while defining a network. the Department may have a set of standards for systems design.• • • • when the Department is issuing an RFP that contains a design When the design team of the Department is preparing designs for its internal use while developing or building systems When the supplier is proposing a system and must include a design with the proposal When one of the products or services a supplier is delivering includes a systems design.

2) 3) To avoid this problem. they can be approved and hence. They should not replace Technical Specifications. The presentation of the design in the RFP will be read by private sector parties. An independent objective review may pinpoint design weaknesses that are hard to see by the team developing them. What to do with Demonstrations? many disputes arise from Departments acquiring software only presented before agreement through live demonstrations. it may be useful to submit the design to experts outside the Department. A good practice is to ensure that the design. development. delivery. Acceptance Criteria : Once the party authorized to approve the design has issued its approval. Such parties can be other ICT Units in the Government or independent third parties such as Consultants. consider demonstrations only as a means of clarifying various functionalities. released as the Technical Terms of Reference. The ICT Processes Page 55 . They would be used as a review of the “qualitative aspects” of the systems. Some designs that are included in RFPs are only clear to the parties that developed them. Documentation or Deliverables : 1) 2) 3) 4) The design documents All supporting documents Standards for accepting Specifications Specification Qualification Review report Good Practices and Recommendations : 1) In the case of complex designs. installation and use. Such demonstrations are risky because : • • • Demonstrations are almost never complete Demonstrations may hide a lot of problems with the system Systems being demonstrated may not be the same as those being delivered and it is difficult to compare the two.system design that can be used for later construction. the Qualification of Specification is considered as accepted. is very clearly presented. 6) Approve the Specifications : once the Specifications are seen as fit.

Standard Installation Procedures : these are SOP’s that define Standard Installation procedure for each type of system or deliverable being installed.Activity 24 : Installation Qualification (IQ) Objectives : before an ICT System is brought into use. software or systems related to networks and telecommunications. The installation acceptance criteria without which the Department will not be able to establish whether a system has been properly installed or not. These intentions could have been expressed through : • • • • • Design specifications System specifications Manufacturers' recommendations Developers’ recommendations Data sheets Scope of usage : hardware. it should be properly installed and confirmed as being capable of operation. 2) The ICT Processes Page 56 . Definition : Installation qualification (IQ) is the documented verification that all key aspects of the installation adhere to approved intentions. The objective of this Activity is to provide an SOP for the Qualification of installation of a wide variety of systems. Risks : the lack of proper installation qualification will result in the following risks : • • • • Disputes regarding what was and was not delivered Items or services are missed while delivery is taking place causing delays and losses during later parts of the operation or the project Improper installation may result Discrepancies between what was ordered and what was delivered Standard Operating Procedure : 1) Identify the party that will approve the installation. The SOP should contain the following : • • • The step by step installation procedure The tests needed to verify that the installation has been carried out successfully. The party should be given the authority to approve the IQ. This is essentially a delivery process and should not be confused with operational qualification to be discussed in the next Activity. Installation procedures should be defined ahead of time by various parties depending on the nature of the system being delivered. The SOP will ensure that all components of the ICT System are installed as per the specifications of the supplier or developer. This may be a single user or a Technical Evaluation Committee.

and room conditions. 5) 6) Acceptance Criteria : the system is fully installed when the installation process is fulfilled as per the supplied Installation Procedure. The documents will be subjected to Configuration Control and must be registered in the Configuration. It would then be ready for Operational Qualification. Should such a procedure not be available. System Documentation : a list of all system documentation promised to be delivered with the system should be compiled and tested against delivery of such documents. 3) 4) 5) Install the system as per the standard instructions and confirm each step. Document all installation problems for later use in Risk Analysis. then the ICT Department should prepare one to ensure that the system is being installed according to a standard process. The ICT Processes Page 57 . Record all the test results. insist that Suppliers provide Installation procedures. power. Environment : make sure that physical location or site meets the installation conditions specified in the system documentation for such factors as air conditioning.• • Site or environmental conditions necessary for the proper installation of the system. Without these. The party authorized to carry out the installation. Ensure that all related software is the proper version for the installation. Update the Configuration Management database to reflect the installation. Documentation and Deliverables : 1) 2) 3) 4) 5) Standards Installation Procedures for the type of system in question The test results produced by the Installation Procedure A document confirming the proper installation of the system in question.3) A list of all documentation submitted with the system A list of all components in the system to be used for Configuration Management Good Practices and Recommendations : 1) 2) 3) 4) In all agreements. The procedure may also include guidelines and related options. proper IQ cannot take place. low moisture. Pass or fail the installed products.

year. Performance implies that other factors such as loads. Example : a software developer may install a full software application and confirm that it can be launched. A system that has been properly installed is not often tested for proper use and operation. Before bringing such systems into full operation. The system may be operated by the wrong persons Major deficiencies may exist in the system to be identified during later stages of its operation (End of month.Activity 25 : Operational Qualification (OQ) Objectives : Operational qualification (OQ) is the documented verification that each unit or subsystem operates as intended throughout its anticipated operating range. However. software or systems related to networks and telecommunications. The objective of this Activity is to provide an SOP for the Qualification of Operation of a wide variety of systems. some menu items can be accessed and it can be shut down without error. OQ consists of such assurances and questions as the following : • • • • Do key functions of the system operate correctly as specified in the design? Does the system have the ability to operate all the software that either came with it or was installed on it as part of the installation procedure? Can we demonstrate that the functions are working properly without errors and missing functionalities? Can the system connect to all its units. volumes and other capacity and power related issues are not problematic. this does not mean that it is fully operational. OQ tests the built-in capabilities of the new system. This is dealt with in the Activity 26 : Performance Qualification (PQ). 2) Difference between Operation and Performance : OQ implies that all functions and features promised with the system must be operational. they should be properly tested and confirmed as operating properly. etc). In OQ there is a focus on specific functions and how these functions can be tested. Standard Operating Procedure : The ICT Processes Page 58 . Many ICT systems can be installed and confirmed to be ready to operate without being fully operational. be networked or be directly connected and use the connectivity for the various functions involved? There are two clarifications to be made : 1) Difference between installation and operation : there is often a confusion between installation and operation. Risks : improper or lack of operation qualification may lead to the following : • • • The Department may not be able to know whether the system can operate properly or not. Scope of usage : hardware.

there are many systems that get passed for regular operation leaving out of zone tests such as closing of periods or the use of large values during data entry or the testing of record sharing and locking in multi-user environments. Installation : ensure that the system has been installed properly through a review of the Installation Qualifications results. Acceptance Criteria : the system is fully operational when the test process is completed and no errors or missing functions are noted. the Department may need to consult the Performance Qualification Activity. This may be a single user or a Technical Evaluation Committee. Record all the test results. For example. Note that operation may be completed and yet the system may not be performing properly.1) Identify the party that will approve the Operational Qualification. A list of all test results A list of possible causes and remedies in case the errors are diagnosed while operating. This can be carried out by the supplier of the system or by persons identified in Step 1 above. Usually. Operating Instructions : Ensure that the system has the proper operating instructions. Good Practices and Recommendations : 1) 2) Include users in the test process Cover all “testing zones”. For this. knowledge or time. Pass or fail the products or services. the reason is due to lack of data. It is these tests that will decide whether the system is “Qualified” as operational or not. Operating Instructions should be defined ahead of time by various parties depending on the nature of the system being tested. Test Procedures : ensure that the system has proper test procedures. These could be SOP’s that define operation or use procedures for each aspect of the system being tested. 2) 3) 4) 5) 6) 7) Documentation and Deliverables : 1) 2) 3) 4) Standards Operating Procedures for the type of system in question A document confirming the proper operation of the system in question. The party should be given the authority to approve the OQ. Operate each function of the system to ensure that they are in working order. The ICT Processes Page 59 .

Standard Operating Procedure : The following procedure is used to qualify if a system is running within its proper “ “Zone” of performance : 1) Defining the operating environment : a description of the use of the system in the context of the work environment should be developed. power. Performance Qualification (PQ) ensures that the total system performs as intended in the specified operating range.Activity 26 : Performance Qualification (PQ) Objectives : Performance is a measure of various parameters in a system such as speed. Scope of usage : the system includes all hardware and software components. people and procedures that make up the system. response. Wrong measures are used. associated equipment. Supplier agreements may be closed making it difficult to hold them responsible for performance problems. Lack of knowledge of the indicators that define whether the measurements are within or outside the proper ranges. it should be specified that this system is to be used by the employees in the Department during their office hours from 8:00 till 14:00. Measurements taken in wrong environments or using wrong data. Which systems should be tested? • • • • • • • • • • New systems that are being delivered and used for the first time Existing systems to be qualified on a regular basis Systems that have undergone modifications Systems that have had additional usage Systems that have seen sudden deterioration of performance should be tested and qualified Systems expanded to operate at a higher capacity Lack of knowledge as to what constitutes a performance measurement. By the time that problems arise. the Department may face the following risks : • • • Systems will slow down or break down during critical periods causing time losses and interruption of operations It will be difficult to hold suppliers responsible for performance problems if these are not tested properly. Setting operational limits : the SOP shall include testing the system against (but not exceeding) its operational capacity. For example. etc. Risks : should Performance Qualification not take place. 2) The ICT Processes Page 60 . capacity. The aim of this Activity is to develop a Standard Operating Procedure that allows the Department to verify that its systems are performing the way they should.

They should simulate the operation of the system in a live situation. Initialize the database to purge all transaction records 2.000 transaction records. 4) Requirements for setting up the data : should it be required to setup special data for the tests. the response time for accessing a Citizen’s record should not be longer than 2 second. Therefore. etc). Whatever data is to be used.The performance levels should be set by the user but should not exceed the rated capacity provided by the supplier. using all system components and operating procedures. Generate test data as per part 3 of the SOP. then the procedure and requirements for such setup should be documented in the SOP. Opening a web page and viewing all images on the Intranet should take no more than 1 second. The purpose is to test the response of the system using a Search program when 20 users are busy posting transaction vouchers : 1. create 50. These indicators define the expected results of the test or the qualification. 5) The ICT Processes Page 61 . Test Procedures or scripts : the SOP must contain one or more Qualification Scripts that describe the procedures needed to verify the performance of the system against the User Requirements or the Indicators established earlier. (This is not included in this example but can briefly be introduced as : create 200 citizen records. Here are some examples of indicators : • • • When 20 users are using the system. Users will often refuse to use actual data stating that the data is not representative. 3) Test Data : disputes will arise when different parties do not agree as to what data is to be used. Agreements do not often specify that and Suppliers are tempted to use test data rather than actual data. Here is an example of a typical database application test procedure or script. the SOP should define what the Qualification Data is : actual data for a full month? A full year? Random data generated specifically for the Qualification? Abnormal data or data which is outside the operating ranges should also be tested to ensure that it is handled correctly in the system. A set of measurement indicators should be developed and approved before running the Performance Qualification (PQ) Scripts. Preparing a full statement of all certificates should not take longer than 15 minutes. the justification for using it should be documented.

The ICT Processes Page 62 . Make ready a test station and log onto the system. Unexpected Results : systems may crash or show unexpected behavior. 6. 7. Once the last of the 20 users is left working for 10 minutes. As each user starts. 9. Prepare the users to start entry of vouchers without interruption. then a summary report should be written. 4. there should be no entry. This should be documented for later analysis. 8. the test is over. Screen prints or electronic logs should be retained to verify the results. The program will display all citizens that meet the entered location. It should include such information as : • • • • Whether or not the qualification scripts were followed Whether or not the expected results were attained Description of any deviation from expected results Any follow-up activities to correct any deviations Documentation and Deliverables : 1) 2) 3) 4) The definition of the environment The operating limits of the system The Performance test scripts The Qualification Report to include all test results. unexpected behavior and any remedial action that is required for correct performance. Since test procedures are often carried out by persons not located in the same room. 6) Test Results : enter the test results in form reserved for such results in the SOP. Do not search yet. two steps are required : • • Diagnose the problem causing the lack of performance Initiate remedial action 7) 8) The system should then be resubmitted for Performance Qualification. Plot the response time as the users come on to the system and analyze the results. The executor should record. A supervisor will time the start of entry so that users start one after the other with a 5 minutes interval. For the moment. Should the SOP result in disqualifying the system. 9) Qualification Report : if the PQ generates extensive documentation. Launch a the program that searches for citizens using the location parameter. it is necessary to have a good way of communicating the procedure and ensuring that all users know how to execute it. 5. They should be ready to use the Transactions entry program when instructed to do so.3. sign and date the results. the tester at the test station will search for the citizens and note down the time it took the system to respond. Have 20 users log onto the system.

the data used and the results obtained when the historical data was generated must be clear. These are available commercially. that item is considered as passed. However. (Example : some systems have their memory reduced to be installed on other systems.Good Practices and Recommendations : 1) When systems are being designed or acquired from Suppliers. the Change Control history for that system must be analyzed to ensure that no changes have been introduced which would affect test results. Data may need to be charted or analyzed for averages. the actions taken. it would be the right time to establish broad lines for Performance Qualification. At a later date. When remedial action is to be taken. In some situations where performance suddenly deteriorates. In this case. 2) 3) 4) 5) 6) Acceptance Criteria : Upon the successful completion of a Performance Qualification SOP for each system. there may not be qualifications scripts. The ICT Processes Page 63 . automated testing tools may be used to record results. then the subsequent PQ will be subjected to the same conditions. historical information may be used. The PQ should always be performed at the user site and will include testing specific to the user environment and defined ways of working. etc. application. Where appropriate. trends. This would affect test results). more specific SOPs can refine the qualification criteria. standard deviations. While carrying out Performance Qualification tests. etc.

0 : Physical System Protection. Some procedures can only be executed by persons with the proper background and training. This is called the Logical System Access facility and is different from the Physical access to the ICT Systems site. posting vouchers should be identified by the person who posted them. damage and interference to business premises and information To prevent loss. 3) 4) Objectives The objectives of the ICT Process of Logical System Access are : 1) 2) 3) 4) 5) 6) 7) To prevent unauthorized access. (Example : the health sector may have storage of disease history for citizens which are confidential). damage or compromise of information assets To prevent interruption of business activities To ensure that only specific personnel carry out specific functions To prevent compromise or theft of information and information processing facilities. The ICT Processes Page 64 . authenticity and integrity of information The last Activity in this Section discusses the current Security Standard within the ISO certification.0 Logical System Access and Security ICT Systems need to be secured so that specific functions can only be accessed by specific staff.5. The latter is defined in Section 6. Some information procedures may put the Department under a liability and hence should be secured. Some processes are the responsibilities of specific persons and must therefore not be processed by others. Access and Security. To protect the confidentiality. To detect unauthorized activities. This creates the necessary transparency. For example. Why should ICT Systems be Secured? 1) 2) ICT Systems process information of a confidential nature.

List all types of ICT systems to be secured (See above list under scope as a guideline) Define the functions to be secured in each system. • 5) If the privilege is subject to an expiry period. to update. etc. For each item in the functions list there would be a definition of the kind of accesses that may be allowed. or change payment date. it is a good time to establish some of the above accesses and privileges. then this has to be defined. he or she will need to have special privilege to view specific data elements within the record. to write. These can be of various types or levels : • • Record level : access to read. a user can create a purchase order but will need privileged access to update the exchange rate. Good Practices and Recommendations : 1) Privileges in customized software : when software is being designed. Many system designers leave the security at the level of the database and hence. This is useful when employees are given time restricted privileges such as when the supervisor is on leave and hands over his or her duties to someone else. Define the nature of access. Scope of usage : typical functions are : • • • • Access Access Access Access to to to to the network a specific PC desktop a particular database application specific web sites Standard Operating Procedure : 1) 2) 3) 4) The Department’s management must decide who can prepare such a list. to delete records on the database Data element level : this is more specific than record level security. Documentation and Deliverables : the list of Accesses or Privileges. If a use can view a record. For example. etc. For example : a user may view the full purchase order but will need privileged access to view the purchase price. or to view the salaries on employee records.Activity 27 : Identify Functions to be Secured Objectives : in order to control logical access to the ICT systems. expose the system to more than necessary. Function level : this is where the user can access major functions but will need privileged access to activate minor functions within them. The ICT Processes Page 65 . These are called Privileges. the Department has to prepare a complete list of all functions that are to be secured.

There is not one way of encrypting data. The Guide can only recommend that the Department look into the facility of encrypting data that is to be secured. Encryption may be used to further secure the access. Knowing that password will allow intruders to access the database from outside the application. this was not possible because encrypting the data had a detrimental effect on system performance. Today’s systems are more powerful and can handle the load of encryption. Special care must be had to ensure that such a password is protected either by making it dynamic or by changing it frequently. 3) 4) Remote Access to Site : some Departments provide remote sites access to their system. These sites are to be secured so that no illegal access takes place. It is important to be able to log the remote access and analyze it. the tendency is to encrypt the data using modern encryption methods. the communications protocols should be secured. As discussed in the previous paragraph. The ICT Processes Page 66 .2) Vendor security : database engines are often secured by a single password. In the past. Acceptance Criteria : The list is considered accepted when the Management approve its content. It is important to ensure that all access from such sites is password controlled. Patterns in the usage of remote access may show illegal attempts at access. Encryption : as hackers become more capable of penetrating systems. Should the access be through wide area networks.

all secretaries will have the same set of privileges. Such software may have holes from which unauthorized persons may access functions they are not authorized to access. The above two lists will form a matrix or a spreadsheet. In each row. the next Activity is that of determining the staff who can access the various functions and assign them these privileges. enter the type of access. On the other hand. The ICT Processes Page 67 . Group the staff by groups to ease the task of assigning privileges. under the column Exchange Rates and across from the Chief Accountant row. a specific person. read or retrieve. Standard Operating Procedure : 1) 2) 4) 5) The Department’s management must decide who can assign such privileges to the various members of staff. Documentation and Deliverables : the list of all staff and their related Privileges and Access Rights. Secondly. Ensure that the previous Activity of identifying all Privileges and Access Rights has been completed. All the privileges defined in the previous Activity must be included. update or delete a currency record. will have only R under his name because he can only Retrieve the exchange rate but not delete it. At the top of each column. they may then be restricted from privileges they are supposed to use because of the change. Good Practices and Recommendations : 1) Review the list periodically as Staff may change posts and may retain privileges they are not supposed to have.Activity 28 : Assign Privileges and Access Rights Objectives : having identified the functions to be secured on the ICT systems. update it or create a new currency code. For example. Scope of usage : all staff who can access the system must be included. Prepare a list of all staff who might be able to access the system. such as the Store Keeper. you can enter ALL to signify that this person can create. A new secretary will automatically inherit the same privileges as the rest of the group. enter the name of the staff. 4) 2) Acceptance Criteria : The list is considered accepted when the Management approve its content. For example. Review the list of Privileges regularly as new software is introduced or existing software is modified or enhanced.

Risks : without such an SOP. This task must be authorized in writing. Good Practices and Recommendations : 1) In some cases. This avoids theft of passwords. Users should be instructed to regularly change their passwords. This is a very secure document and must be stored where it cannot be located except by the Management who issued it and the Superuser. This is a procedure that allows the Department access to the list in case it is lost or access to the system breaks down. They should be either part of the senior management or entrusted to this task by the Senior Management. A Superuser ID and password will be assigned to each Superuser by the Management or sometimes. assigning them the Privileges and Access Rights defined in the earlier Activity. the system may be able to display the list of all users and their passwords. Such lists can be left in escrow with a Bank or parties that the Department can trust. Scope of usage : all staff on the list prepared in the Activity 28 : Assign Privileges and Access Rights. Instruct Users on how to prepare their own passwords. Such a privilege should only be given to the Superuser and the Senior Management. 2) 3) 4) Documentation and Deliverables : The list of IDs and Passwords. by the Supplier. On the other hand. This Activity presents an SOP that ensures that the process itself is safe. if passwords are 2) 3) 5) The ICT Processes Page 68 . Each Superuser can then create Logon IDs and Passwords for the staff. dates of birth. Users will be informed of their IDs and Passwords through some scheme such as email or sealed envelopes. Checks on this can be made at random. Most users tend to use such easy passwords as their phone numbers. Standard Operating Procedure : 1) Assign at least two Superusers in charge of all password assignments. it is time to setup the procedure for assigning passwords to staff. (See Good Practices below). Leakage of Superuser passwords or password lists will cause the Department to be exposed to insecure systems. Distribute and Control Passwords Objectives : once the list of all functions is prepared and all staff are given the proper privileges of accessing the ICT systems. These are targets for hacking.Activity 29 : Assign. It is good practice to keep the password list outside the Department. names of children or loved ones.

The ICT Processes Page 69 . it is best to implement some security procedures that avoid illegal access such as the following : • • • 7) Suspend the screen if a user enters a faulty password more than 3 times in a row within a specific time. It is a good practice to analyze transgressions so that the Department can tell that specific areas are target to attack. Many systems are assigned passwords that can be cracked by the Suppliers or are even set by Suppliers. say 15 minutes. 6) In the case of tailored software. The Guide proposes that users resort to complex words that have an easy to remember “sound” but have no meaning. These have to be checked to ensure that only persons within the Department have such passwords. no one can remember them and users may write them down where they are easily accessed. Passwords such as kledobim and friklasiv can be remember but cannot be guessed.very complex. 8) 9) Acceptance Criteria : The list is considered accepted when the Management approves its content. One of the two owners of Superuser rights should regularly check his or her access to ensure that he or she has not been deliberately or inadvertently shut out. Prepare weekly or fortnightly system warnings for users to change their passwords Stamp all records with the ID of the user who created the record and the ID of the user who last modified it. This is a good audit trail. storage and means of frequent update. This is to be avoided.

Activity 30 : ISO Standards for Security Objectives : ISO has established a standard for security (ISO17799) which is slowly getting implemented in a variety of ICT systems. What is the use of ISO17799? The standard is intended to serve as a single reference point for identifying a range of controls needed for most situations where ICT systems are used in industry and commerce facilitation of trading in a trusted environment Background The standard was first published as a Department of Trade and Industry Code of Practice in the UK. In February 1995. Supporting tools start to appear and it was soon published as an ISO standard. its acceptance was delayed because there were other issues such as Y2K. Furthermore. even as far back as the BS7799. A major revision took place with the issue of Version 2 in May 1999 and within the same year. At that time. it was repackaged and published by British Standards as Version 1 of BS7799. etc. It is an internationally recognized generic information security standard. This Activity introduces this standard and prepares for its implementation. What is happening now? There is major activity taking place in terms of using the standard : • • • Many organizations in the West are quoting intent to use the standard Some are well on route to certification Some organizations already certified through BS7799 are converting to ISO17799 General Description The Standard. What is ISO17799? ISO17799 is a comprehensive set of controls comprising best practices in information security. was made up of 10 sections : • • • • • • • • • • Security Policy Security Organization Assets Classification and control Personnel security Physical and environmental security Computer and network security System access control Systems development and maintenance Business continuity planning Compliance The ICT Processes Page 70 . formal certification and accreditation schemes were launched. it was not accepted widely because it was not flexible enough.

The above sections cover 10 Key Controls • • • • • • • • • • Information security policy document Allocation of information security responsibilities Information Security Education & Training Reporting of Security Incidents Virus Controls Business Continuity Planning Process Control of proprietary software copying Safeguarding of organizational records Data Protection Compliance with security policy Good Practices Embarking on a full certification is a complex task. it should seriously consider the structure of the Standard and start implementing the controls even without the aim of certification. However. The ICT Processes Page 71 . if the Department is strongly interested in Information Security.

6. For example. access and security levels (Or the countermeasures that are expected for each item). A list of the physical protection. Indeed. Any remedial actions taken. 3) 4) 5) Documentation and Deliverables : 1) 2) 3) 4) A list of all items to be reviewed or surveyed. the Department can select to remedy any shortcomings according to its needs. budgets and practical considerations. Access and Security The following set of Activities are concerned with the following aspects of the Information Resources : • • • • Physical Protection Physical Access Security Practical usage The next few Activities shall adopt a different format due to the nature of the items being reviewed. the Guide will not present the reader with the best ways to test cables or install servers. Standard Operating Procedure : here is the procedure recommended for all items : 1) 2) An inventory list is to be prepared of the existing Information Resources. The other presents a list of recommended countermeasures. the baseline is then updated. Note : the Guide does not provide technical guidance. the Department can consider surveying the above material on an ongoing basis to ensure that the ICT Resources are secure and protected.0 Physical System Protection. the Department needs to setup its own list. two major paragraphs are presented. The Department can then form a baseline by surveying all the items and checking whether the countermeasures exist or not. However. this would be based on the items presented in this Section. The survey results including suggestions for remedial actions. it is best to use the Configuration Management database. After the survey. One presents a list of possible threats or risks. If implemented. Thereafter. These are part of the technical specifications and would be covered as per the guidelines of Activity 23 : Specification Qualification (SQ). Each one will have a set of countermeasures (Which automatically point to the risk to be avoided) and a set of recommended good practices. Using the items on the list. Normally. The ICT Processes Page 72 .

the Building would have its own Physical Protection and Access schemes. Refer to the introduction of this Section for an SOP that covers this Activity as well as for other Infrastructural items. data media. The objective of this Activity is to list the various items that fall under Server Rooms and other Computer locations and identify the threats and related countermeasures need to avoid them. additional equipment. Risks : there are various risks involved in the handling of rooms or physical sites. etc. These are avoided by the following countermeasures : Recommended Countermeasures Adapted segmentation of power circuits Hand-held fire extinguishers Use of safety doors Closed windows and doors Intruder and fire/smoke detection devices Avoidance of water pipes Overvoltage protection Emergency circuit-breakers Proper earthing schemes Air conditioning with positive outward airflow Local uninterruptible power supply (UPS) Remote indication of malfunctions Redundancies in the technical infrastructure (Additional hubs. etc) Development and use of Standard Technical and Organizational requirements for server rooms Door key management Supervising or escorting outside staff and/or visitors Entry regulations and controls Inspection rounds Ban on smoking Monitoring of access to the room Shielding or change of location to avoid interference : electromagnetic radiation. cellular networks or generators. Scope of usage : there are various rooms that should have special considerations such as : • • • • • • Server Rooms Mainframe or mini-computer centers Media Archives Storage centers Technical Infrastructure Rooms Computer Centers Protective cabinets (Which may house servers) These rooms usually accommodate documentation.Activity 31 : Infrastructure – Server and Other Rooms Objectives : should the ICT Unit be hosted in a dedicated building. However. The ICT Processes Page 73 . these are so similar to measures and practices taken for other computer rooms that the Guide has grouped them together.

4) The ICT Processes Page 74 . The rooms should not be occupied by regular staff. a fax machine or photocopier. must be located outside such rooms. Combustible materials such as printer paper should not be stored in such rooms.Lightning protection devices Availability of plans detailing the location of supply lines Alert plan and fire drills Good Practices 1) 2) 3) Any devices or equipment which require access by a large user group. e. They should be used only randomly and for short-term assignments.g. These can cause considerable interference with the operation of the systems. Avoid the use in computer centers of mobile phones or other units that have transmission/reception facilities such as walkie-talkies and pagers.

The ICT Processes Page 75 . bridges. routers. The objective of this Activity is to list the various items that fall under cabling and identify the threats and related countermeasures need to avoid them. of unneeded lines Selection of an appropriate network topography Selection of types suitable for required bandwidth Documentation on cabling and related markings Minimizing routing of cables to avoid damage Provision of redundant lines Avoid proximity to power or other interference sources Good Practices 1) Make available all cabling plans and drawings in an easily recognized location. gateways. couplers. Their scope is from any existing delivery point of an extraneous network (telephone. It is often the case that other infrastructural technicians may need to work on the structures and would hence be helped by tracing the cables. ISDN) to the terminal points of network subscribers. These are avoided by the following countermeasures : Recommended Countermeasures Fire sealing of trays Selection of cable types suited in terms of their physical/mechanical properties Sufficient dimensioning of lines Physical protection of lines and distributors Prevention of transient currents on shielding Neutral documentation in distributors Monitoring of existing lines Removal. or short-circuiting and grounding.Activity 32 : Infrastructure – Cabling Objectives : cabling of ICT Systems covers all cables and passive components of networks. Scope of usage : network components such as the following are considered as equipment and are not dealt with in this Activity : Repeaters. Refer to the introduction of this Section for an SOP that covers this Activity as well as for other Infrastructural items. Risks : there are various risks involved in cabling. etc.

The objective of this Activity is to list the various items that fall under networking and identify the threats and related countermeasures need to avoid them. Scope of usage : the following is applicable to different types of networks : • • • • • • Server-Based networks Networked Unix Systems Peer-to-Peer networks Windows NT networks Novell Netware based networks Heterogeneous networks This Activity does not take network operating systems or the operating systems of client PCs into account. Risks : there are various risks involved in the handling of networks. Refer to the introduction of this Section for an SOP that covers this Activity as well as for other Infrastructural items. These are avoided by the following countermeasures : Recommended Countermeasures Ban on using non-approved software Survey of the software held Escrow of passwords Documentation on the system configuration Designation of an administrator and his deputy Documentation on authorized users and their privileges Establishment of a restricted user environment Documentation on changes made to existing ICT systems Obtaining information on security weaknesses of the system Division of administrator roles in PC networks Training before actual use of a program Training of maintenance and administration staff Password protection for ICT systems Use of memory resident virus detection programs that check for viruses coming through the network Periodic runs of a virus detection programs to scan full systems Restrictions on access to accounts and/or terminals Blocking and erasure of unneeded accounts and terminals Network management Regular data backup Sporadic checks of the restorability of backups Possible removal of hard disks or floppies from client stations Good Practices The ICT Processes Page 76 .Activity 33 : Infrastructure – Networks Objectives : networking of ICT Systems covers all components of networks.

Such systems should support the system administrators as much as possible in their daily work. Network management includes all the precautions and activities for securing the effective use of a network such as : • • • Checking that the network components are functioning correctly Monitoring the network performance Centrally configuring of the network components 2) Use a suitable System Management application which is concerned with the management of distributed ICT Systems. This includes : • • • • • • • The central administration of the users The distribution of software The management of the applications Configuration management Performance management Error management Security management The ICT Processes Page 77 .1) Use a suitable Network Management System. This is used to control all the hardware and software components located in the local network.

Secondly. Review the list periodically. Risks : not assigning Physical Access Privileges properly will cause the Department to be exposed to insecure operations. they may then be restricted from areas they are supposed to use. Identify all systems that need to be physically secured and their locations. At the top of each column. you can then indicate the type of access for that staff. cards. Scope of usage : all staff who can access the system must be included. Prepare a list of all staff who can access the system. etc. the Department can then issue passwords.Activity 34 : Assign Physical Access Privileges Objectives : to determine the staff who can access the various areas in the Computer Center and assign them these privileges. etc. temporary. worker. Use password protected door locks Standard Operating Procedure : 1) 2) 3) 4) The Department’s management must decide who can assign such privileges to the various members of staff. In each cell where a row and a column meet. Types of access can be : visitor. Types of Physical Access Control Schemes A Department may introduce different types of physical access control schemes such as the following : 1) 2) 3) Monitor entry manually through registration at the desk and the issuance of visitor badges Use automated badge card readers and provide staff with cards that can access specific areas in the center. The above two lists will form a matrix or a worksheet. enter the staff names. enter the system/locations of access. 5) Depending on the type of Access System used. The ICT Processes Page 78 . Documentation and Deliverables : the list of all staff and their related Physical Access Privileges. Good Practices and Recommendations : 1) Staff may change posts and may retain Physical Access privileges they are not supposed to have. In each row of this worksheet.

When necessary. it is important that persons entering are properly checked through the use of their IDs. The ICT Processes Page 79 . Acceptance Criteria : the list is considered accepted when the Management approve its content. etc. staff cards.2) In the case of access control through registry at the reception. it can be dictated that such persons never enter the site on their own but that they are escorted by an authorized staff member.

They should be either part of senior management or entrusted to this task by the Senior Management. This avoids theft of passwords. Such lists can be left in escrow with a Bank or parties that the Department can trust. This task must be authorized in writing. The ICT Processes Page 80 .Activity 35 : Assign. Risks : this is a very risky activity. This Activity aims at setting up the procedure for assigning passwords and/or distributing access cards to staff. The Access Administrator needs to regularly change passwords. Scope of usage : all staff on the list prepared in the Activity 34 : Assign Physical Access Privileges. Users will be informed of their Passwords through some scheme such as email or sealed envelopes. Checks on this can be made at random. Distribute and Control Passwords Objectives : in some cases. This is a procedure that allows the Department access to the list in case it is lost or access to the location where the list is kept is not possible. Leakage of passwords or password lists will cause the Department to be exposed to insecure systems. storage and means of frequent update. 2) Acceptance Criteria : the list is considered accepted when the Management approves its content. Physical Access to ICT locations may require passwords. This is a very secure document and must be stored where it cannot be located except by the Management who issued it and the Access Administrator. The Access Administrator will then handle the creation of Passwords for all staff and the production of the access cards. 2) 3) Documentation and Deliverables : The list of and Passwords and/or the list of assigned Access Cards. Standard Operating Procedure : 1) The Department’s management must assign at least two Access Administrators in charge of all password assignments and card distribution. Such schemes as password protected door locks and cards require issuing policies. Good Practices and Recommendations : 1) It is good practice to keep the password list outside the Department. Cards are also distributed through a secure scheme to ensure that the right person has received the right card.

Review paragraph (3) in the Activity 44 : Disaster Recovery – Good Practices. scanners. Loss may take place due to theft. Backup media may be destroyed due to various reasons. etc. Loss of Work : loss of time spent on work caused by Force Majeure or other damaging situations can be insured. Loss of Source Code : this often happens in different ways. operating and other documentation form a major part of the ICT resources. Loss of documentation : training. damages due to various reasons or acts of civil strife. loss or theft. communications components. Scope of usage : insurance can cover a variety of losses. cost of the emergency procedures. losses can be averted by proper backup. increased Risk Analysis and better physical security management as shown in the previous Activities in this Section. The financial value of a Department’s systems along with related equipment may reach a high enough value to warrant such an insurance. printers. Source code may be corrupted. reinstallation of software and systems. These can easily be insured. negligence. Source code may become inaccessible for various reasons. etc. Wrong backup may take place.Activity 36 : Insure the ICT Systems Objectives : to present a set of Good Practices that aim at insuring the various ICT resources in the Department. various works can be insured. Such work can be insured : recovery costs. etc. These can easily be insured against theft. reentry of data. These are defined in the Good Practices section below. 2) 3) 4) 5) In many cases. corruption of media. rework. The ICT Processes Page 81 . The Department can also insure itself against such losses. Loss of Software Products : some of the more expensive products can be insured. sabotage. Good Practices and Recommendations : 1) Equipment : all equipment such as computers. Such documentation can be lost due to theft. can be insured proportional to their financial value. In the case of setting up a Disaster Recovery System. water.

some centers use it to signify removal of the data or cyclical backup that is not very frequent. The reasons are many : equipment breakdown. operator error. software bugs. The only effective measure that can be taken to ensure that Information Integrity is maintained in an acceptable state is to have a rigorous Backup and Archiving policy. etc.. (Review Activity 43 : Disaster Recovery Procedures) The following Activities present various procedures and good practices related to the above. In all cases. Archiving : this term is essentially the same as Backup.0 Information Integrity : Backup / Archiving and Data Protection One of the most frequent causes of damage or the highest risks in ICT Systems is loss of data or its corruption. etc. the procedures are the same as for Backup. Purging : removing data from the initial medium to make space or reduce database size. scripts. Some Definitions Backup is the storage of data. Checkpoints : these are points in time where the Department has to take a full backup so that disaster recovery schemes can be used to restart the system from such Checkpoints. source code. The ICT Processes Page 82 . Example : transactions are kept within the operational database for the current and the most recent 3 years.7. the ICT Unit would need to purge the oldest year from the database. On completion of each year. on a separate medium that can be used to restore the data to its initial form if need be. so this Guide will not differentiate between the Backup and Archiving. software products. However. This could be a regular or an ad hoc activity.

etc. 3) The ICT Processes Page 83 .Activity 37 : Identify What is to be Backed Up and When Objectives : the purpose of this Activity is to document the data and software that needs to be backed up and/or purged. Standard Operating Procedure : 1) 2) Classify the types of data to be backed up as suitable for the Department. These should be backed up with all related transaction and parameter files. monthly. weekly. Prepare the Backup Definition List which contains the following data elements : • The frequency of backup : daily. it is inappropriate to backup master files on their own. For example. List all data in appropriate groups. Refer to the Scope of Backup above for a proposed classification. These are targets for back up : Operational data (Used by the various software applications) Development data Source Code Scripts Web pages Graphics used in screens Documentation and help files Test scripts Test plans Operating data Shell scripts Operating Instructions Software products Libraries Compiled systems (To avoid recompilation on restore) Off the Shelf Commercial Software Updates / Upgrades / Patches Operating Systems / Tools / Utilities User Data Data that is processed on client stations and centrally stored on servers Reports ASCII based output COLD technology output : Computer Output on Laser Disks Acrobat Reader output (PDF files) Risks : not preparing a proper list of items to be backed up will cause the Department to be exposed to loss of data. Scope of usage : the following is a recommended list of data and software but is not restricted to these items. end of cycle. A Back Definition List will define the scope of the data and will include a variety of information about each specific backup.

The Backup Definition List may be setup on the Configuration Management database if that is suitable. 2) 3) Acceptance Criteria : the Backup Definition List is considered accepted when the Management approves its content. The ICT Processes Page 84 . However. Who is to carry out the backup? Good Practices : 1) User Input : it is good practice to include users when defining the Backup Definition List. Users usually have a good sense of how to avoid data loss and would indicate at which critical points backup is to be made. backup should take place. Changes to the list can then be controlled. 4) Regularly review the Backup Definition List as it often arises that new systems or situations arise such as those in the previous paragraph that will require the Department to update the list. there are other times when backup becomes necessary : At the end of specific business cycles Before migration to new systems (Equipment or software) Before upgrading/updating software or introducing patches Before relocating systems Before introducing new staff/users to the system In fact. any time the Department feels that there will be a risk of data corruption. When to backup? Most centers tend to backup at specific frequencies such as end of day. The type of backup : is this an incremental backup or does it fully replace the data? Is it a purge or a copy? Etc. end of week. The type of backup media and where it will be located.• • • • When to backup? : in case backups are required on an ad hoc basis. storage and means of frequent update.

Good Practices and Recommendations : 1) Centralization of the Backup Register : in the case where Departments have several sites. Copies of printed forms can be sent to such a location. This is the most crucial Activity to be carried out by the Department and it aims at maintaining Information in total integrity. but it is an insurance against data loss or corruption. Complete the backup and fill in a register that has the following recommended columns : Date of backup Time of backup Type of backup (Incremental. or different databases can be consolidated on a regular basis. 3) The ICT Processes Page 85 . applications. it would be necessary to have a centralized register. Many centers lose valuable data because media is not available and operators end up backing up over backed up media with useful data.Activity 38 : Backing Up Objectives : to prepare a Backup procedure observing all backup requirements stated in the Backup Definition List and to ensure that there is a record of all backups taken for all types of information. If the register is setup on a minor database. Backup Media : ensure that there is available media for the backup well in advance of the backup itself. It may be time consuming and it may be costly. etc. etc) Source data : describe it and its status ID of the backup as per the Backup Definition List (Refer to Activity 37 : Identify What is to be Backed Up and When) Operator Media type Media label Where the media is to be stored Has restored testing been tried? Result of restore testing Remarks Documentation and Deliverables : The backup register which can be a printed form or a database. purge. then it can either be located centrally and made accessible to all operators. Standard Operating Procedure : 1) 2) Consult the Backup Definition List on a regular basis to ensure that no backup is missed. servers. Risks : not backing up the data on a regular basis will cause the Department to be exposed to loss of data and software items. full.

This should be part of the Acceptance Criteria of the Backup Register preparation. the Backup Register should be checked against the Backup Definition List prepared in the earlier Activity 37 : Identify What is to be Backed Up and When. On a regular basis.2) 3) Configuration Management : it may be suitable to setup the Backup Register as part of the Configuration Management database. restore checking should be made on random or specific backups. (To facilitate matters. and this will be discussed in the next Activity. In order to do that. Verification can be made that all items in the Backup Definition List are being properly backed up. Securing Backup : some centers follow the recommended practice of carrying out the backup by well trained personnel. the Backup Register should be checked against the actual media. some security measures may be implemented so that only such persons can carry out the backup. More importantly. Review the Activity 41 : Good Back Up Practices 4) Acceptance Criteria : 1) On a regular basis. 2) 2) The ICT Processes Page 86 . Verification can be made that the backup entries correspond totally to the stored media. the Backup Definition List ID is included in the Backup Register).

Define the mode of testing : is this a simple hardware test? Is it a logical data checking test? Etc. The main reason for such a state is the lack of testing of the backed up media. Risks : not testing backed up data will cause the Department to be exposed to loss of data and software items. 2) For each item in the Restore Definition List. Users usually have a good sense of what is risky in their work. Physically restore the data into the hard disk Logically restore the data into the database server (Import. end of financial period. The ID of that item would then be known.Activity 39 : Identify What is to be “Restore Tested” and When Objectives : many centers face major upsets upon realizing that their backed up media is badly backed up or is corrupted. A typical test plan is presented below : • • • • • • • Prepare sufficient space on the local disk Ensure that the versions of the operating system that is running. when and what constitutes a good Test Plan. Compare the above list with the same list produced on the day when backup was made. Pass or fail the test Documentation and Deliverables : the Restore Definition List. Run the program that presents a list of system parameters : number of items. etc. how frequently and what the tests are. monthly. it is a matter of deterioration of the backed up media or its environmental corruption. number of citizens. etc. A new List can then be prepared which can be called the Restore Definition List. prepare a Test Plan that covers all aspects of the Restore and its testing. Standard Operating Procedure 1) Identify the type of data to be Restore Tested and enter the relevant information on the Backup Definition List prepared in Activity 37 : Identify What is to be Backed Up and When. This Activity presents a procedure that defines what media is to be “Restore Tested”.). For each item in the Restore Definition List : • • 3) Define the frequency of restore testing : daily. etc. the version of the application software and the database structure are all compatible. number of transactions. Good Practices : 1) User Input : it is good practice to include the users when defining the Restore Definition List. Sometimes. The ICT Processes Page 87 . They would help the ICT Unit identify which data is to be tested. Scope of usage : all data that is backed up may be subjected to Restore Testing. weekly.

Acceptance Criteria : the Restore Definition List is considered accepted when the Management approves its content. Changes to the list can then be controlled.2) The Restore Definition List may be setup on the Configuration Management database if that is suitable. The ICT Processes Page 88 . storage and means of frequent update.

It becomes the responsibility of operators to do one of two things : Data recovery is possible : the operators will recover the data through some means like reindexing. 7) In all cases. purge. Prepare a Register that shows the Restore Test details and results : Identify the ID of the backed up media to get all the data elements for it Date of Restore test Time of Restore test Type of backup (Incremental. If the Restore Test fails. remedial actions Remarks 5) 6) Pass or fail the test as per the Test Plan. enter the data related to the Restore Test in a Restore Test Register. it may have to be re-entered and processed. In case of needing such data.Activity 40 : Restore Testing Objectives : this Activity presents a procedure that allows the Department to reduce the risk of bad backup media through regular Restore Testing. However. full. the operators would need to give warning to the ICT Unit Management and the user. etc) Operator Test script or plan Result of restore testing Pass or Fail If fail. etc. Data recovery is not possible : if neither of the above schemes is possible. The ICT Processes Page 89 . it is too costly and time consuming to test all backed up media. they can get the data from duplicate media stored outside the Department. Scope of usage : in most cases. Risks : not carrying out restore testing will cause the Department to be exposed to loss of data. Alternatively. Prepare the receiving system for the Restore and restore the data Apply the Restore Test Plan as indicated in the Restore Definition List. frequent and random tests can reduce the risk of damaging situations. the Department would have unusable data. that such data is not available. Standard Operating Procedure : 1) 2) 3) 4) Consult the Restore Definition List to identify the items that require Restore Testing.

some security measures may be implemented so that only such persons can carry out such Tests. Auditing Restore Testing : similarly. Securing Restore Testing : some centers follow the recommended practice of carrying out the Restore Testing by well trained personnel. the Restore Register should be checked against the Restore Definition List prepared in the earlier Activity 39 : Identify What is to be “Restore Tested” and When. In order to do that. Good Practices and Recommendations : 1) 2) 3) It is important to relate Restore Testing with the Business Continuity Process discussed in the next Section. Verification can be made that all items in the Restore Definition List have been properly tested. 4) Acceptance Criteria : On a regular basis. Configuration Management : it may be suitable to setup the Restore Register as part of the Configuration Management database. The ICT Processes Page 90 . some centers may wish to have auditors or user representatives on the spot when such tests are carried out.Documentation and Deliverables : the Restore Test Register.

it does present an additional load on the network since processing requires data traffic with the server. 4) Rotational Backup : ensure that there is a daily backup for all operational data that is stored on separate media so that there is a tape for Monday. What to do with Local Data? With the increasing spread of PCs on user desks. This is more efficient in terms of network traffic but is slightly more risky as the data is as fresh as the most recent backup. so that no other person than the specific user can access such a hierarchy. Once a week. The above scheme therefore requires : 2) 3) The ICT Processes Page 91 . Good Practices and Recommendations : 1) Media Availability : ensure that there is available media for the backup well in advance of the backup itself. There are two solutions to this problem : Server based data : force users to work on a folder hierarchy that is setup on the Server and is secure. This presents a risk to the Department because users are not very disciplined about their own backups. prepare an end of week tape separately for each week in the month. Once a month.Activity 41 : Good Back Up Practices Objectives : the main aim of this Activity is to present a set of Good Practices that apply to the variety of back up procedures presented so far. prepare an end of month tape separately for each month in the year. This is a safe process. scripts can be prepared to push that data from the local folders to secure folders on the Server. These can be kept as archives. However. Scope of usage : covers all types of data backup. Many centers lose valuable data because media is not available and operators end up backing up over valid and much needed backed up media. the operators are never sure which data it contains. Labeling is important but not sufficient. one for Tuesday. This should also include Directory or File Listing so that file dates are clearly shown. larger and larger portions of a Department’s information will be processed on these local PCs. Locally based data that is regularly backed up : users can be shown how to concentrate all their data in one main folder hierarchy on their own PC. Labeling Procedures : one of the major problems facing ICT Units is that when a backup medium is required for restore. On a regular basis. etc. These can be rotated during the next week. These can be rotated during the next month. A rigorous scheme for labeling must be followed and should be linked to the Backup Definition List identification.

etc. the RAID technology allows such mirroring with the facility of hot swapping in case of breakdowns. etc. 8) Automating Backup : there are products in the market that automate the tasks of Backup with such features as : scheduling. Media Technology : change in technology is becoming frequent. Furthermore. 5) Offsite Locations : ensure that duplicate backups made for key periods such as end of week or end of month or end of key closing periods are stored outside the site to avoid theft. It is therefore highly recommended to include in the above list backups whereby existing backups are duplicated on other media. This can present a problem. damage or loss. Some may even require hourly backup.7 daily tapes that can be reused 4 weekly tapes that can be reused 12 monthly tapes for each year Of course. tracking. Usually. Both are then kept in case of need. The same would apply to 3 inch floppies. that all backed up data gets migrated onto more popular media. It is recommended that such software be used. It is highly recommended that when the ICT Unit feels that a specific backup media is being slowly phased out of the market (As what happened with the LSI-120 disks). some Departments may consider the above too risky and would need to establish daily or weekly backups that are rotated less frequently. they do not have a 5 inch floppy drive or that it has not been tested and is not operational. it is best to store such off site backup media with a Bank or a branch of the Department. For example : some centers are finding that they have a mass of 5 inch floppies as a back up only to find that on a specific day. incremental backup. 6) 7) 9) The ICT Processes Page 92 . Media Duplication : often magnetic media spoils with time. This is also recommended. Mirroring : disk systems can be duplicated to allow the system to use mirroring of data. DAT tapes and CD-ROMs one day.

Review the earlier activities in this Section for a discussion of backup procedures. 2) 3) 4) 5) 6) The ICT Processes Page 93 . These have to be licensed to run on the various machines in the center. Good Practices and Recommendations : 1) Backup : one of the best insurance schemes against infection is proper data backup.com/VIL/hoaxes.Activity 42 : Protection Against Viruses Objectives : viruses are increasing in their damaging capability as well as the way they carry out such damages.europe. Many centers wrongly assume that if they have the latest version of the software. In the case where a center cannot remove a CD drive because of its internal use.com/hoax. stop access to systems. Virus hoaxes : even though there are many virus hoaxes. Some centers disable all such units. it may be required to implement strict techniques about using data on floppies or CDs or zip drive disks coming from the outside. it becomes critical to discipline users to scan CDs for viruses before using them. In web sites. System scans : on a regular basis. This can be carried out at night when there is no work load on the system. This includes all operating or application software. Use up to date virus definitions : ensure that a responsible person regular checks and updates the data definitions of the viruses. The aim of this Activity is to provide Good Practices that reduce the problems associated with Virus infection to a minimum. There are several sites on the web published by the major anti-virus developers that list the hoax viruses. they are protected.htm http://vil. scan the whole system including zipped files. Developers of anti-virus products frequently release new virus definitions to meet this surge.asp? These and other sites will also list real viruses and explain what their effect is and they can be treated.com/news/hoax. Risks : virus can corrupt data.nai. Others remove them completely. wipe out files and cause system slow down. Use up to date anti-virus products with the latest patches and upgrades.f-secure. they may create a denial of access to the site or even redirect traffic. Virus warnings sent by mail should be checked against these sites.mcafee. Importing data into the site : in the sites where there is a lot of traffic of data to and from the outside world. Here are some examples : http://www.asp http://vil. It is estimated that 200 new viruses are identified per month. it is better to be safe than sorry. Stories should be believed until proven innocent.

Stoppages that result in indefinite interruptions or interruptions that have an unknown resumption time. The Plans should include : Contingency procedures as well as Disaster Recovery procedures. 1) Disaster Recovery Procedures describe how the Department can obtain alternate ICT resources in the event of the primary systems being unavailable.8. 8. These procedures would be followed if the system is to be down for longer than manual procedures could feasibly be used. Contingency Procedures describe how the functions provided by the system can be performed manually in the event of the system being unavailable.2 The recommended solutions cover different types of disasters. The following Activities provide Procedures and Good Practices for the following types of interruptions : 1) 2) Stoppages within the center that result in an interruption of a few days. Contingency Procedures are described in the Activity 45 : Business Continuity – Contingency Plans. Such situations as the following can cause disasters : • • • • • • • • Civil strife Lack of access due to security reasons Flooding or water seepage Total electrical failure Construction damages Extreme weather conditions Chemical or toxic gases Etc Whatever the case the Department’s ICT Processes should guarantee that there is a continuity of the Department’s business by setting up countermeasures to such failures and disasters. Disaster Recovery Procedures are described in the Activity 43 : Disaster Recovery Procedures and Activity 44 : Disaster Recovery – Good Practices. Classifying Disasters 2) 8. Departments may modify these terms to suit their own "urgencies".1 Business Continuity Plans Such plans should be available to describe how the Department can continue to operate in the event of its ICT Systems not being available. Such a stoppage is short enough not to require relocation of the total system. These can be further sub-classified as follows : The ICT Processes Page 94 .0 Information Integrity : Business Continuity Planning Force Majeure situations may occur and disrupt business at the Department over periods of different lengths.

etc.Small sites Non-critical sites Medium sites with large operating volumes Sites that are semi-critical Mission Critical Sites no matter how large The Guide will provide three main Activities to ensure Business Continuity by grouping the above 5 types of sites into 3 groups. Semi-critical or medium sites as in the next Activity but only in the case where the stoppage is known to take less than is justifiable for a full disaster recovery. maintenance costs. private companies. The ICT Processes Page 95 . Mission Critical Sites • • • • Sites whose interruption is considered to be a disaster Sites whose users are in the public domain : citizens. Sites that do not operate in real-time Sites that do not have external users such as private sector companies. citizens or banks. the Department must analyze their requirements in the case of a disaster. In determining the appropriate solution. and recovery time. citizens or banks. Department inconvenience. overseas users. Medium and Semi-Critical Sites • • • • Semi-critical sites that operate with central applications Sites that may operate in real-time Sites that do not operate in real time but have short cycles such as daily closing. Sites that have real time operations that depend on minute by minute up to date information Sites that depend on the Internet for their processing. banks. The analysis must consider up front costs. Notice that the first type of stoppage is considered non-critical and will be considered as part of the first group : Small and Non-Critical Sites or Short Stoppages • • • • • Non-critical sites that operate batch based applications Non-critical sites that solely use office technology products. Sites that have external users such as private sector companies. The solutions provided below range from a cost effective to a mission critical solution.

Activity 43 : Disaster Recovery Procedures Objectives : there is a variety of situations that can be considered disastrous depending on the criticality and the size of the site in question as well as on the nature and duration of the distaster. When a disaster takes place, the Department has to move to an Alternate System. This is called the Recovery System. All software and data will be recovered on such a system. However, there are different ways of acquiring such a system depending on the classification of the disaster defined at the beginning of this Section. This Activity presents a general procedure for dealing with the recovery from disasters. The following are broad steps to be followed depending on the size of site and criticality of that site : Recovery Systems for Small and Non-Critical Sites 1) 2) 3) Acquire another similar system. This may take time. Recover all software and data Resume operations

Recovery Systems for Medium and Semi-Critical Sites 1) 2) 3) Prepare an agreement with another center a distant from the current site so that the equipment in that center can be used in emergency situations. Recover all software and data Resume operations

Recovery Systems for Mission Critical Sites 1) On a regular basis, take a Checkpoint backup and restore it on the Recovery System in anticipation of a disaster. Being mission critical, Checkpoint backup may be very frequent, say twice a day. (Review the start of Section 7.0 : Information Integrity : Backup / Archiving and Data Protection). Acquire a mirror system through purchase or agreement with a third party for use in such situations. The system need not have the same capacity as the current system. Minimally, it should be able to run the mission critical applications. Install the software and ensure that the operating environments are compatible. In an emergency situation, the Department can resume its work from the latest Checkpoint.


3) 4)

Note : in the following discussion, the Guide will not differentiate between the above choices but will present a generic Disaster Recovery Procedure or Plan for all types. Standard Operating Procedure The Minimal Requirements for Recovery are :

The ICT Processes

Page 96


Prepare the following documentation before the Disaster : Emergency Procedures : describes the immediate action to be taken following a major incident which jeopardizes business operations. Such actions are usually not ICT related and would cover such activities as : moving files or special equipment, ensuring personnel get to the new location, moving support to the new location, informing external users such as citizens or companies of the change, etc. Responsibles : specify the individuals responsible for executing each component of the plan. Configuration : prepare a document that describes the configuration of the recovery system to avoid reconfiguring such elements as user names, passwords, directory structure, service packs, etc. The Recovery Procedure : a document that describes the Recovery Procedure in a step by step fashion. The Recovery Test Plan : a document that shows the procedure needed to certify that the Recovery has been properly executed. For example, the Test Plan can include : File counts File sizes Tests on various reports (Transaction listings, etc) Database record counts Date checking Etc Related Documents : other documents prepared by related activities such as Security lists, Backup Registers, etc. Keep the above documents ready outside the Department so that they can be immediately accessed in the case of Disaster.


Prepare whatever is necessary to ensure access to a Recovery System as selected for the particular site from the choices presented at the beginning of this Activity. Note that even if agreements exist for such systems, the organization in question might also be under the same disaster, so it is preferable to have recourse to more than one such site.


Backup Media : prepare an offsite location for the backup media. It is recommended that the media be stored at a significant distance from both the Production and the Recovery environment in order to avoid total loss in the event of a widespread disaster. It is vital that the backed up media can be accessed in a hurry, so again, it is best to have recourse to multiple backups in different sites.

The ICT Processes

Page 97


Disaster Specific Backup : on a regular basis, take a back up of the full system. The point at which the backup is taken is called the Checkpoint. Backups at Checkpoints should be “operation ready”. This means that all the Operating System and the related software tools should be backed up in a recoverable form to avoid re-installation in the new recovery site. (Note that this is not the same as the regular data backup taken by most Departments). The frequency of such backup should be commensurate with the time of stoppage that the Department can afford. For example, if the Department is worried about interruptions that may last more than 1 week, then the backup should be taken at least once a week, preferably on daily basis.

Recovery Procedure 1) 2) 3) 4) 5) Setup the new Production environment according to the documented Recovery Procedure. Restore the backed media from the latest Checkpoint. Conduct a test of the recovery procedure as per the Test Plan prepared earlier. Inform all users as to when they can start in the sequence of their work. This totally depends on the most recent restoration of the data. Open access to users.

The ICT Processes

Page 98

sites. Testing : as in the case of Backup. Ensure that Disasters are included in the Risk Events to be analyzed in the Department. in some cases. Therefore. It is recommended that such activities be insured so that the Department can recover parts of its losses. Therefore. The following Good Practices are suggested as a support to the Disaster Recovery Procedures of the previous Activity 1) Outsourcing : the major servers needed as Recovery Systems may not always be available within the Department. Disaster Recovery is a kind of a “Restore” operation.Activity 44 : Disaster Recovery – Good Practices Objectives : the previous Activity presented a procedure for handling the recovery from disaster by preparing alternative systems. Risk Analysis : much of the cost and time loss of the Disaster Recovery can be avoided by a rigorous Risk Analysis of such situations. Indeed. 4) Training drills : an emergency is sue to have people lose their heads. relocation. Furthermore. Insurance : not all problems generated by the Disaster can be resolved by a Disaster Recovery Procedure. Outsourcing of servers. any outsourcing to be made to have access to such systems must be submitted to rigorous qualification. 2) 3) 5) The ICT Processes Page 99 . data entry. A lot of cost and effort is required to setup of a Recovery System : The increase in backup frequency Repeat work that is lost during Emergency and Recovery Replacement of equipment Additional running costs such as transportation. This Activity supplements the previous Activity by presenting good practices to be followed when handling such situations. it is critical to regularly test the alternate site to ensure that the Recovery System is ready for operation. etc. etc. It is therefore crucial in semi-critical and critical situations to have training drills on Emergency and Recovery Procedures. it is crucial to test the Recovery on a regular basis by simulating a disaster. it has been known to resort to such systems outside the country.

only the accumulated costs). then manually update the statement by adding one line by hand showing the specifics of the particular transaction. The ICT Processes Page 100 . most organizations forget how to process their work in a manual fashion and end up losing time and money in case Disasters take place. prepare a summary list of all totals (In the above case. change of department. etc. The Procedure will generally consist of the following structure : • • • • 3) Define the reports that define the status of the data at specific checkpoints. etc). it is essential to have recourse to Manual Operating Procedures. entry of distance counter. Entry of project data is one such procedure. change of vehicle particulars (Color. For example. In case cumulative totals are required such as in the case of Maintenance Costs. Standard Operating Procedure : 1) 2) Prepare a Procedure for each of the information processes within the system. There will be a list identifying the following vouchers : change of location. Technology being addictive. 1) 2) 3) 4) Prepare the Vehicles list from separate media As each voucher is received. entry of maintenance summary. Example : the following is a typical procedure for the Maintenance of the Vehicle Fleet in the Ministry of Public Works : Prerequisites : a daily list showing all vehicles with transactions on each starting from the beginning of the month. The aim of this Activity is to prepare a procedure that defines how Manual Operating Procedures can take place in case the ICT Systems are not available. Upon resuming the system. Documentation and Deliverables : all manual procedures. Identify the transactions through their manual vouchers Define the procedure used to update the data manually and check it Define the procedure to be used upon re-starting the system On turning into the Manual procedure. On a weekly basis. follow the steps of each of the above procedures. these can be computed on the hard copy report. entry of petrol usage. chassis. the operators can re-enter the data directly from the manually prepared transaction histories.Activity 45 : Business Continuity – Contingency Plans Objectives : as an insurance against the possibility that a system may not be available for any reason.

The basic reason is simple. there are many competing processes. This leads to communications problems and hence disputes. Project Management principles are still not being applied 2) 3) Software Development Processes (SDPs) have started arising and as is normal in such situations. as was successfully done in the Construction Industry. It is known that some companies do both resulting in inefficient projects and software. It points to a document that describes SDPs in full that can be downloaded from OMSAR’s web site. the ICT industry has been plagued with problems that were and still are mostly caused by poor software. The Software Technology is still young and has not had the chance to develop a standard methodology for architecture and contracting.9. or the Software Developers of systems. The ICT Processes Page 101 . There is no standard and efficient Business Modeling language that allows Software Developers to “draw” their systems in the manner that Architects draw their buildings and bridges. Some of the major Problems with Software Processes : 1) There is no clear separation between Architects or Designers of systems and the Contractors. This Section covers a variety of issues relating to Software Development.0 Software Application Development Throughout the past 30 years.

The Guide will not present such a procedure. Selecting and adapting an SDP is not a simple matter. Risks : not using a Software Development Process may result in the following risks : • • • • • Non standardized approach to programming and development Lack of reuse of components Poor and nonstandard documentation Inefficient project planning Inefficient life cycle phases : poor requirements analysis. This is to emphasize that they are not simple step by step “Procedures”. design. this Activity will define software development processes. monitor and control the development of software products from the stage when such products are conceived as basic concepts up to the point where the developed products are delivered and certified as operational. testing and other activities. This is presented in the Activity 19 : How to Audit or Qualify Suppliers. Scope of usage : this covers any software development effort whether for : 1) 2) Internal Usage : when a Department wishes to develop its own software applications. many have failed in the past because they were forced into tight waterfall “Procedures”. Background : a Software Development Process (SDP) as defined as : A method whose objective is to plan. execute. However. business analysis. emphasize their importance and provide guidelines on how to select them. It is critical to note that SDPs are called “Processes”. Suppliers delivery customized software applications to the Department may suffer from a similar shortcoming. it requires to select and use an SDP OR for Usage by Suppliers : when a Department wishes to investigate the SDP that a supplier who develops software applications uses. Indeed. Why the Guide cannot recommend a single SDP? The reasons for not providing a recommendation are the following : • • • • There is no standard internationally accepted SPD that can be recommended Describing typical SPDs requires extensive discussion Different applications may require different SPDs Different development platforms may require different SPDs The ICT Processes Page 102 .Activity 46 : Using a Software Development Process Objectives : Most ICT Units suffer from not having a defined and documented Software Development Process (SPD).

As the technology changes. building. Various organizations fall into the trap of applying an SDP only to start drifting from its standardized procedures. It must rely on Modern Project Management practices Be based on a modern modeling scheme so that the documentation across its phases is visual. The ICT Processes Page 103 . testing. Within each phase. SDPs must have characteristics : • • • • A methodology that follows a Project Plan and not just tips and techniques for development. With the above restrictions.org.• • SDPs require discipline and are hence more than just a Standard Operating Procedure. there will be a variety of processes such as analysis. testing and implementation must be avoided.pmi. Once an SDP is introduced. Documentation must be a high priority for the process. Good Practices and Recommendations : 1) It is important to recognize that SDPs are either commercially available products or are products that may be learnt from various academic resources such as books and web sites. special effort must be put on maintaining its practices as planned. The waterfall method of analysis. simple and accepted internationally The SDP must not have a strict waterfall approach. design. SDPs change. development. the Guide will neither be able to recommend a specific Standard Operating Procedure for an SDP nor provide a set of Good Practices for one. The Department needs to research both areas for a proper SDP. The alternative is a two dimensional approach where the phases correspond to those of a modern project as discussed in the Project Management Institute’s site at www. supervision and monitoring to get properly implemented as well as adaptation. etc. Reuse of components Must be flexible and it must be subject to reconfiguration so that it can be used in different environments. A case in hand is the emergence of the Internet which caused a revision to many standard development processes. They may require training. Platform and development language independent Application independent Rely on horizontal Teamwork as opposed to Hierarchical structures Iterative and incremental Development Efficient and Quality controlled Requirements Management The use of Component Architecture Traceability of models Relies on Risk Management 2) • • • • • • • • • • • 3) 4) Selecting the SDP must submit to the same procedures presented in Activity 49 : Selecting Software Applications. design.

Activity 47 : Software Development Tools Objectives : various development tools and platforms (Database systems) can be used to assist the software development process. This Activity highlights the importance of using such tools. It also presents some of them and emphasizes the need to justify them operationally and financially. Scope of usage : software tools are needed to support the Software Development Process selected by the Department. Risks : not using the proper software development tools would result in the following risks : • • • • • Delays and increased development costs Reduction of the quality of the development process and the software itself Using the wrong tools would also result in inefficiencies and higher costs Using tools that are not standardized across the Department will result in inefficiencies and higher costs There is a risk of not using tools if those selected are too advanced and require extensive training

Good Practices and Recommendations : 1) Here is a list of such tools (Presented under generic titles) CASE Tools Integrated Development Environments Commercially available libraries of components, routines, etc Business Modeling tools Source code repositories Debuggers Automated testing systems Commercially available Software Development Processes Help file generators Code generators Report generators Data warehousing and OLAP tools 2) 3) 4) The Department should select the products that it requires and present a justification for their acquisition. The justification should be documented. Proper training should be had of all such tools otherwise they will not be efficiently used. Tools that enforce a standard must be widely utilized as the tools would have a negative impact if part of the Department does and the other part does not use them. It is often possible to acquire trial or evaluation products that can be used and tested before purchasing them.


The ICT Processes

Page 104

Activity 48 : Programming Standards Objectives : with the large number of development platforms, and due to the hurried nature of development itself, the development profession has not been able to standardize its work. There are many reasons for this shortcoming that the Guide shall not go into. However, the Guide will recommend a set of Good Practices that serve to establish programming standards. Scope of usage : the scope of this Activity is not limited to one development platform but is presented as a generic set of practices to be setup for each. Risks : having poor or no standards will result in the following : • • • • • • Code that cannot be understood or even read by others Code that is difficult to debug and test Code that is difficult to reuse Duplication of effort, variables, file names, etc. Code that may result in technical hitches, system crashes, hangs, etc. Code that may produce errors and bugs

Good Practices and Recommendations : 1) 2) 3) Study the development platform under use and establish Programming Standards that apply to it. Publish the standards and ensure compliance with them. This can be carried out by frequent checking, dry testing and code review. The following are the areas that need to be addressed when setting up a Programming Standards document. Review web sites and academic material for work already done in these areas, especially if a specific development platform is in use : • • • • • • • • • • • • • • • • • • Access to Hardware Argument Passing Comments Data Declarations Defining Constants Documentation Error Handling Function Declarations and Returns Function Layout Including Files Modular Coding Module Layout Naming Files Naming Variables Source Code Formatting Standard techniques and algorithms Style consistency Version Control

The ICT Processes

Page 105

• 4)

Using objects

The Department should use source code repositories. These have the following useful features : • • • • • Librarian control on individual modules to avoid them being modified by different coders at the same time. Allows development by teams Facilitates version tracking Tracks modular and reusable code by sharing files between projects Provides security on source code access

Such products as Microsoft Visual SourceSafe™ are typical of source code repositories and can even be used for a variety of other work such as storage of project documents, specifications, office technology documents, spreadsheets, etc.

The ICT Processes

Page 106

he has the proper experience in supporting the product. Without a proper specification of the requirements needed from the specific software. These are test and evaluation scripts that will verify that each of the functions stated in the design or specifications is part of the product and is working as expected. Standard Procedure : 1) Document Requirements : this is part of the design process. This will assist the Department in the task of converting qualitative scores into a single quantitative score based on which the selection can be made.Activity 49 : Selecting Software Applications Objectives : when selecting software applications. This exercise also confirms that the supplier has already installed the product elsewhere and that as such. Create and Issue RFP : where the RFP must include all relevant sections discussed earlier in Activity 22 : Recommended Issues to Consider in ICT Agreements. should be followed during this first step. This Activity presents a Standard Operating Procedure for the selection process. Products. Analyze Proposals : the Department needs to subject the proposals to a disciplined evaluation scheme as described in Activity 21 : Evaluation of Suppliers. the Department can use the recommendations of Activity 19 : How to Audit or Qualify Suppliers to start with a Long List and progressively reduce it to a Short List of Suppliers that can supply the required software product. Scope of usage : covers the selection of all types of software applications and tools. Qualifying the design so that the Department has the proper Specifications was discussed in Activity 23 : Specification Qualification (SQ) and as such. Projects or Alternatives. 5) Visit other user sites : one of the most efficient means of analyzing software products is to view them under actual usage. 2) 3) 4) 6) The ICT Processes Page 107 . Create and Issue Demo Scripts : on receiving the proposals. Research Possible Vendors : this is a multi-step task. sample date. a methodology should be followed different from the selection of other information resources such as equipment and networking items. There should be a logical and manageable progression through the selection process in order to stress on making the selection process Quantitative rather than Qualitative. It depends strongly on the procurement procedures of the Department and of the project in question. the Department must issue scripts to be used in the demonstration of the products. and part of the evaluation of the products. the selection process will be faulty. Briefly. Demo scripts should include such items as scenarios to demonstrate. evaluation criteria and expected results. Especially important is the presentation in the RFP of the basis of the evaluation scheme to be used to select the supplier and the product.

the Activity can be considered complete. operation and performance testing of the software product. The plan must be subject to the criteria established in the various Qualification Processes : Installation.0. The ICT Processes Page 108 . the Supplier and the Department must prepare a final Project Plan for the acquisition. installation. 7) Documentation or Deliverables : 1) 2) 3) 4) 5) 6) 7) Software specifications Evaluation criteria and weights The request for proposal (RFP) Demo or test scripts The test results The evaluation results The implementation project plan Acceptance Criteria : upon the submission of all the above documents. the Supplier will be selected and will hence go into a negotiations phase where the final drafting of the agreement takes place.6) Select Vendor/Software : upon arriving at the best score. Project Plan : in parallel with finalizing the draft agreement. Operation and Performance Qualifications discussed in Section 4.

data flow. Therefore. The Activities that follow cover some procedures related to the Operations Function. Operations include regular data processing as well as some user based work”.10. The ICT Processes Page 109 .0 Operations Management The Appendix of Supplementary Material of this Guide discusses the structure of typical ICT Units. the Guide shall not repeat the functions of data entry. The function of the Operations Unit within the ICT Unit was stated as : “A unit that has the responsibility of seeing all work and operations processed by the ICT Unit completed according to the highest possible quality level. The following Section covers procedures related to the Data Entry functions. etc. One of the major functions in such an organizational structure is that of Operations. The functions of this Unit were clearly stated in the Appendix of Supplementary Material. There are various Procedures and Good Practices that should be followed by the Operations Unit to meet the above objectives. in this Section.

Items outside the list should either be considered for inclusion or given special lower priority treatment. application. intranet web page. These can be used by users to log in their medium to long term problems. Prerequisites for the Standard Operating Procedure : 1) Valid users : establish a list of all persons who can call regarding Maintenance and Support services. software and networks Support of hardware. (This could be linked to the Configuration Management database). the support person can enter the receiving party’s name on the form. analysis and control. Valid items to maintain or support : establish a list of all items that can be supported. third parties supporting or maintaining systems.Activity 50 : Logging Maintenance and Support Objectives : one of the main causes of disputes between the following parties is that lack of coordination on Support and Maintenance : users. During routing. software and networks Application support for users Risks : not having a register will lead to lost calls. improper traceability and reduced analysis of problem causing areas. Persons outside this list should either be considered for inclusion or given special lower priority treatment. They will then be routed accordingly. The ICT Processes Page 110 . email. The latter can be a centralized application. an email form or an intranet web page. Suppliers and the ICT Unit. 2) 3) Maintenance and Support Logging Procedure 1) 2) Each call should be registered or logged on the selected media : printed form. etc. Scope of usage : the procedure covers : • • • Maintenance of hardware. Maintenance and support request form : prepare a printed form or an automated form. The Maintenance and Support Request form should contain the following data : Time/Date Name of User / Department Type of call (To be entered by the user and later modified if need be) Description of problem Priority (To be set by the user) Expected date for completion (To be set by the user) 3) The Calls should be processed by support staff who can tell which one is to be support by which unit. This Activity presents a procedure that defines the means of logging all support calls for the purpose of tracking.

The support person will then review the situation. 5) Documentation and Deliverables : 1) 2) 3) A list of the valid Users A list of the valid Items to Maintain or Support The Call Form Good Practices and Recommendations : 1) Since users generally consider all their problems as high priority. bugs. these should be posted onto the Configuration Management database by the person completing the Maintenance or Support Request. the Requests should be analyzed to arrive at such analyzes as the following : Most frequent calls by : Type of call (Repair. 4) External Maintenance or Support : in case these are to be supplied by Suppliers outside the Department. queries. On a regular basis. it may be a good practice to prepare a Help Desk that filters these calls. the following is entered on the call form : Time/Date started processing the call Time/Date completed processing the call Real problem : as the user may have phrased the problem wrongly. directing the user to note down his or her problem on paper or electronically if that problem is judged to be of medium or low priority. it will be the responsibility of the Support person to liaise between the User and the Suppliers. the support person will enter the actual cause or issue of support. Action taken : describes what was done to solve the problem or give support 6) In case the call is being handled by a Supplier. Whenever there are changes to the Configuration. On completion. then the Supplier must complete the call and fill in some of the information above. preventive maintenance. visiting the user if need be.It will be the responsibility of the Support or Maintenance person to process the Change Request if there is reason to change the Configuration. etc) Department or Unit or Division Equipment Software Networking components Site items How does training vary with the frequency of calls? What is the average time between the following : 2) 3) The ICT Processes Page 111 . Suppliers will receive copies of the Request and will act accordingly.

Time request placed till it was handled Time request started getting handled till it was cleared In how many cases did the request cause system stoppage? Etc The ICT Processes Page 112 .

there is a need to plan and control such dissemination. As this list. The rest can be produced on request. Documentation and Deliverables : • The Reports Distribution List The ICT Processes Page 113 . Establish security levels required for : The production of the reports The viewing of the screens The exporting of the data 6) The Reports Distribution List : by now. produce the reports where it is the responsibility of the Operations Unit to do so. More and more. such information is being converted from paper form to screen displays. Prepare a list of all users and which reports they should receive Configure the system so that user can print on specific printers. with the popularity of exporting data from various databases for use on local employee stations. Risks : not being able to control the dissemination of hard copies may lead to the following risks : • • • Lack of security Overproduction of reports Storage of paper reports instead of on electronic media leading to loss of space Standard Operating Procedure : 1) 2) 3) 4) 5) Prepare a list of all reports. such data is also included. However. Moreover. that is left for the user.Activity 51 : Control Dissemination of Hard Copies and Distribution Objectives : one of the major responsibilities of the Operations Department is the dissemination of the information being processed by the various systems. the Operations Unit would have a list of all reports to be produced for which user and at what frequency. Scope of usage : all displays and reports are included in this Procedure. major screen outputs and exported data Define the frequency of the reports when they are cyclical. The objective of this Activity is to prepare a Procedure that allows the Department to plan the distribution and dissemination of reports applying security whenever this is crucial. otherwise.

users may create queries that are massive which would create heavy loads on the system. users may produce reports that are not valid. For example. However. This generally makes it easy for users to prepare reports directly from the database. Although of great benefit. users can manipulate the data using standard spreadsheet products. training is required for this practice. the design should cater for such security checks at the data element level. Export Data : when systems are being designed. sensitivity and statistical analysis. annotations. By allowing the data to be exported in such format.Good Practices and Recommendations : 1) Electronic Storage : in the past. This would save in printed paper and time of production. With more reliable software. etc. it is recommended that users should be store reports in electronic format on their individual PCs. it may be beneficial for the Department to resort to the use of COLD technology (Computer Output on Laser Disk). it was always the case that reports should be produced for auditing and checking purposes. 3) 4) Acceptance Criteria : The Reports Distribution List should be approved by the Management of the Department before any reports are released. This technology converts any report being sent to a printer into an Acrobat Reader PDF or ASCII text mode in an electronic format providing a variety of search services. Security : sometimes reports have part of their data that needs to be secured. an inventory list in the Municipality’s Vehicles Maintenance Department should be viewed by anyone. General software applications are not capable of charting. The ICT Processes Page 114 . Without proper training the following two risks may be faced : by using wrong fields or wrong conditions on some of the fields. Therefore. Suppliers are supplying “report generating” software along with database structures. not anyone should be able to review the cost prices. it is recommended to select some of the reports and allow them to be exported in spreadsheet format. 2) Report Generators : more and more. Here. Secondly.

This would also translate into a drop in the volume of support calls. etc) The support is for all types of applications and requirements : • • • • Hardware : its fault reporting. It has been regularly shown that properly trained users translates into a major drop in the volume and criticality of support calls. The objective of this Activity is to present a set of Good Practices for the Planning. configuration fault reporting. This applies to the following : • Network Management Software that analyzes all components on connected PCs on a daily basis. This supports Configuration Management and enhances the knowledge of the Department about what each PC contains. Scope of usage : all types of Users : • • • Management Technical and Operational Staff Users accessing the system from outside the Department (Citizens. Good Practices and Recommendations : 1) Ensure that the Procedure defined in Activity 52 : Good Practices for User Support is setup for logging Support Calls. Telecommunications : connections. installation. Risks : not having proper user support may lead to the following problems : • • • • • Inexperienced users handling their own problems Inexperienced users assisting others because of slightly higher experience Lack of procedure for analysis of support calls Lack of user training will lead to increased calls for support Improper Installation. updates. When analyzed. Automate parts of the support. upgrades. This is useful to track calls and follow them up. usage. Execution and Control of User Support. User Support is currently a wider function than simply that of supporting an application. installation. The Support Unit is described in the Appendix of Supplementary Material. Encourage Users to resort to Help Files and user Documentation. preventive maintenance and installation Office Technology Applications : usage. the types of support calls direct the Department towards the solution of the problems causing these calls. Operation and Performance Qualification will lead to increased calls for support. configuration and error reporting. companies. Ensure that Users are properly trained in all products that they use. 2) 3) 4) The ICT Processes Page 115 .Activity 52 : Good Practices for User Support Objectives : with the spread of Office Technology. Running specific applications of the Department.

• • Provide users with Intranet or application based logging of support calls on issues that are not urgent. The ICT Processes Page 116 . Ensure that all software installations are carried out by system support personnel.

Magnetic media should be stored in areas that are protected against interference. On a regular basis. Stationery Backup spare parts such as printer heads. one year). capacity. Shortage of such media can be most damaging. boxes Magnetic media : tapes. Follow the Department’s procurement policies to acquire such material. For example. analyze the above inventory to ensure that there is enough material to avoid shortages. Essentially. modems. Define the expected usage for the next period (Usually. preprinted computer forms. etc. these aim at ensuring that supplies have the right quality. 2) 3) The ICT Processes Page 117 . Pay special attention to Backup Media Control. hubs. Survey the market and qualify the Suppliers and their supplies. floppy drives. power supplies for PCs. diskettes. Prepare an inventory management scheme with an issuing policy so that there is a complete control on the movement of such items. hard disk units for PCs. computer labels. preprinted vouchers. toners.Activity 53 : Managing the Supplies of the ICT Systems Objectives : to present a set of Good Practices that allow the Department to better manage the supplies needed for the various ICT Systems. zip drive media Backup media : CD-R. some computer continuous forms should be stored in computer rooms to avoid humidity which may cause paper jams. CD-RW and DVDs Ink : cartridges. Link of supplies to Configuration Management. Scope of usage : supplies can broadly be grouped as follows : • • • • • • Paper products : blank paper. etc Standard Operating Procedure : 1) 2) 3) 4) 5) 6) Itemize the required supplies. standard and availability. Good Practices and Recommendations : 1) Some supplies have special storage requirements which should be observed. Establish their technical specifications according to the systems in use.

otherwise. 2) On preparing a Data Entry Procedure. most work done on improving the standards of data entry covers the entry of data for operational.Activity 54 : Documenting Data Entry Procedures Objectives : generally. financial or administrative applications. In such a case. it is essential to follow some Data Entry standards or Good Practices. Erroneous or slow entry of data leading to loss of time and re-entry More rigorous training of new staff Standard Operating Procedure : 1) For each data entry form in each software application. Whenever the Department is developing its own systems or requesting such systems to be developed by third parties. the Department should check if such procedures are sufficient. the software would have such procedures if it is well documented. administrative and financial application software. Risks : not having proper data entry procedures would lead to the following : • • • Improper entry of data causing errors. they would be used as the basis for a redeveloped Data Entry Procedure. rework and possibly damages with citizens and other users of the data. Generally. this would apply to data entry for operational. in some cases. there are data entry procedures that are covered by Office Technology products. it should be tested to ensure that all data elements are clearly explained and that the procedure is easy to understand and use. This Activity presents some Good Practices for ensuring that all data entry procedures are properly documented. However. These are either developed for the Department or acquired as Commercial products. These are presented in the Appendix of Supplementary Material. These latter are discussed under the Activity 56 : Using and Supporting Office Technology Products later on in this Section. Scope of usage : generally. a detailed Data Entry Procedure is to be prepared. 3) The ICT Processes Page 118 . The Data Entry procedure would be used in the following cases : Training Day to day entry tasks Validation and consistency checking Auditing purposes Refreshing the user A Sample Data Entry Procedure is presented in the Appendix of Supplementary Material.

Along with this checking. Data Integrity : various systems are designed without proper data integrity. Such areas should be investigated and checked on a regular basis to ensure that there is Data Integrity. The batch is not updated or posted to the database unless the computed total equals the entered total. Throughout the years. One of its fields is accumulated manually. there are many Inventory Management systems that allow the quantity to go negative. the term got distorted to mean the following : a list of transactions as entered. The ICT Processes Page 119 . There are cases where the accounting vouchers posted from an operational module do not correspond to the totals recognized by the accounting system. For example. say the amount on the voucher. A batch of vouchers is entered. The batch or Audit Trail is entered into the system. They can then be accepted. they should be registered and totaled. purchases in the Inventory Management system do not correspond to the total inventory in the Accounting System.4) Error analysis should be carried out. The batch is controlled as one single group of vouchers by the system. 5) 6) Documentation and Deliverables : all Data Entry procedures Acceptance Criteria : data entry procedures are critical and must be validated by the developers of the software and the users in the related Departments. Upon full validation that such procedures are corrected. Use Audit Trails when possible. it is recommended that they be tested. If specific forms are found to generate more errors than others. the system must be able to produce a validation list of all vouchers before committing the entry. then there is the possibility that the form is not being properly understood or that it may have programming problems. When errors are reported. Audit trails technically mean the following. This is not correct. For example. Audit Trails are rigorous ways of verifying proper data entry.

Choices (Yes. the CV database presented in the Appendix of Supplementary Material can be presented over two pages with buttons that will show other screens for the entry of work. under privilege control. to add a parameter that is not in a lookup table on the spot without having to go to another screen. This should be available during deletions. contractors. No. Error and Warning messages through the proper use of buttons : Info (OK). Cancel). Many systems suffer from temporary entries that are never completd. it is best to use TABs or even multiple screens. This eases data entry and requires less training for the user Use clear color coding as per Windows standards : Black labels.Activity 55 : Standard Data Entry Checks and Controls Objectives : when developing or acquiring software applications. • The above guidelines should be standardized across various applications to ensure that users get familiar with the look and feel of applications and hence require less training. Warning (Yes. The ICT Processes Page 120 . Good Practices and Recommendations : The following types of checks and controls are important to have in the data entry screens in all software applications : • • • • • • • • • Validate all field that have ranges such as dates or amounts Try to increase the number of lookup tables so that users do not enter country codes or currencies whichever way they wish. education and training experience. Error (OK). modifications. Design screen layouts to be similar to actual vouchers. etc. Allow the user to search for major tables such as citizens. printing and other system functions. Use clear and unambiguous messages Avoid cluttering the screen with a large number of fields. No). White for enterable fields and Grayed fields for non-enterable or for system responses Differentiate between Info. it is important to ensure that the data being entered is properly checked. This Activity presents guidelines for data entry checks and controls. It becomes difficult to visually scan the screen and validate the data. projects. In the case of large number of fields. Allow the user. Do not allow the system to accept to create or modify a record unless all data is validated. For example.

This is due to lack of proper training and poor practices. faxing products. illustrators (Visio). Another may use a spreadsheet to prepare budgeting exercises. it is best that a standardized naming procedure is followed. This Activity covers a variety of recommendations. However. Scope of usage : covers all PC based applications that are used on a stand alone basis by the users. Risks : not following good practices in this area : • • • • • Creates a confused environment that is not standardized Increases dependence on user support Reduces the efficiency of training Exposes the Department to data and document losses May cause deterioration of network response if not organized properly Good Practices and Recommendations : 1) User Training : one of the most prevalent problems is that of lack of familiarity with Office Technology Products (OTP) in use. personal information managers. spreadsheets. a certain Ministry may use a word processor to prepare various authorizations or certificates. etc. Should the use of such products not be organized properly. This covers such products as word processors. they are on their own without assistance. minor databases (Access). web page editors and a variety of other office technology products. it is more important to encourage users to use other products which are not so obvious such as slideshows (Powerpoint). as soon as users hit difficulties. Standardized File Naming : for files that are used internally and between different users. For example. damages may result and worse still. The first step to ensure proper use of Office Technology Products is to provide regular training of users. Most products are simple to “start using”. For example. It does not require much more effort to improve the competence in such products. get the next reference. However. Encouraging use of office technology products : most users will be happy using 10% of a word processor and a spreadsheet. illustrators. email. register the certificate on the 2) 3) 4) The ICT Processes Page 121 . duplication and difficulties while backing up. This has the added benefit of allowing easier support and backup. This may be linked to a reference generator that is setup on a published register. This usually results in document losses. the products will be underutilized. It is recommended that the Department establish a standardized directory or folder structure that can be used by all users. the user can open a centrally accessible spreadsheet.Activity 56 : Using and Supporting Office Technology Products Objectives : many governmental processes are based on Office Technology Products (OTP) that are end user programmable. on issuing a specific type of certificate. many of them related to standardization of work by the users. minor databases. Standardized Directory Structures : most users have a tendency to create documents all over the disk on their PCs.

absence justification. reference register. The important issue is to ensure that users are aware of the need to backup their documents using whatever method is selected as per Activity 38. It is therefore important to ensure that all users have the same versions of office technology products or at least have the proper converters for such products. supplier names and records. etc. etc. file structure. There are different ways to handle backup and all are discussed in the above Activity. Often. document registers. Information Sharing : invariably in an office environment. this would give the Department a more efficient control of correspondence. Such forms as the following can be standardized : • • • • • • • 7) Outgoing general correspondence Faxes Certificates the Department may issue Authorizations the Department may issue Various procurement forms such as orders. placed orders. project lists. change of status. schedule of events. Various human resource forms such as leave requests. 5) Backup procedures : although discussed in Activity 38 : Backing Up. Using standard forms : many organizations fall in the trap of using different forms for their standard correspond and issues. 8) The ICT Processes Page 122 . Forms can be standardized and setup as templates on the user systems or on the central server. In all cases. Linked with the reference generating practice discussed above. Such information as the following should be shared : telephone lists. it should be sharable. Other types of file naming practices can be introduced such as clear titles. receipts and other financial documents 6) Version Issues : office technology product suppliers often update and upgrade their products resulting in documents not being compatible between one version and the next. Invoices.spreadsheet and use the reference as part of the file name. etc. It is important to survey the Department to identify such information and ensure that it is either centralized or that it resides with the person who is totally responsible for its maintenance. email addresses. etc. change orders. this activity is slightly more complex with user data as such data is not centralized nor standardized. the same information gets logged onto different PCs resulting in duplicated effort and incompatible data. delivery reports. this causes inconvenience and time loss for users exchanging such documents. types of templates.

This is an Information Process that covers the definition of environmental conditions. The ICT Processes Page 123 . the drivers used to maintain such conditions within the correct operating zones and the testers needed to warn against such conditions going out of their operating zones.0 Environment Management Most large computer centers require specific environmental conditions so that the equipment is maintained in proper running order.11.

For example. etc. cabinets. It consists of the development of 5 types of documents : 1) Environmental Factors or Drivers : prepare a list of all environmental factors to be controlled. communications rooms. in case the UPS is not producing the required voltage to run the system. Equipment is required to monitor the environment for such purposes as : • • • To measure various parameters (Temperature. media storage.Activity 57 : Define the Required Environmental Conditions Objectives : this Activity presents a Procedure that defines the technical specifications required of the environment of the site where various ICT systems reside. humidity. Examples such as the following are common : Temperature levels Dust levels Humidity levels Quality. turning on emergency lamps. etc. etc. fire. humidity. server rooms. To act under certain situations. cellular networks and phones. The ICT Processes Page 124 . These are also critical items since in some cases. insurance. Site Engineers and in some cases. temperature. etc) To warn when such situations arise as excessive smoke. Scope of usage : the environment covers large computer sites. stability and continuity of power Radiation interference (Radars. dust. motors. These are technical specifications and should be validated with the Suppliers or the Manufacturers of the Equipment. warranties and maintenance agreements may be voided if the environment is not within its required limits. Not recognizing that the systems are operating outside their proper operating zones and hence expose the Department to environment problems Standard Operating Procedure : The following Procedure should be prepared with the help of Suppliers. the architects of the site. it may send a signal to the servers to shut down normally. etc) Smoke levels Fire Other gases A/C quality Etc 2) Range of Operation : define the ranges allowed for each of the above for the specific site. Risks : not knowing what the proper environmental conditions are may lead to • • Building improper sites : either too lax which may cause system problems or too strict which may require excessive costs.

4) 5) Documentation and Deliverables : the above 5 lists. Acquire such equipment through the proper procurement procedures. warnings or actions. Monitoring Equipment Test Procedures : develop Test Procedures that can be applied to the monitoring equipment itself to ensure that it is running properly. Good Practices and Recommendations : 1) Include all monitors in the Configuration Management database for better tracking. Environmental Drivers Test Procedures : develop Test Procedures that can be applied to the Environmental Drivers to ensure that “in situ” the monitoring equipment is operating properly providing the right measurements.3) Monitoring Equipment : identify the type of monitoring equipment needed to test the above environmental drivers. The ICT Processes Page 125 .

Diagnosis and Remedial Action : in case monitors give results that show that the various environment parameters are veering out of the acceptable operating range. The ICT Processes Page 126 . Document all test results. Risks : having no monitors or faulty monitors can lead to : • • • • Stoppage of work due to the environment creeping out of its valid operating zones Damage to equipment in the short and long term Corruption of data on current and backed up media Voidance of warranties and maintenance terms by Suppliers who will claim that their equipment may have been operating outside their acceptable operating zone. Apply Monitoring Equipment Test Procedures prepared in the previous Activity at the time of installation and on a regular basis to ensure that they provide the proper reading.Activity 58 : Monitor Environmental Behavior Objectives : to monitor the various environmental factors affecting the environment in which the ICT Systems operate and to ensure that the environment is maintained running within its allowable zones. 3) 4) 5) 6) Acceptance Criteria : For each monitor. both the above tests should be passed. Apply the Environmental Drivers Test Procedures prepared in the previous Activity to ensure that unusual environmental behavior is being intercepted and that the proper actions are taken by the equipment. the related parties responsible for such systems should be contacted for diagnosis and remedial action. Ensure that the required monitors as defined in the above lists are acquired on time and installed according to the proper IQ and OQ procedures presented earlier. Standard Operating Procedure : 1) 2) Ensure that the 5 lists required in Activity 57 : Define the Required Environmental Conditions have been properly prepared. give the right alarms or carry out the proper action.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer: Get 4 months of Scribd and The New York Times for just $1.87 per week!

Master Your Semester with a Special Offer from Scribd & The New York Times