PRINCIPLES AND FUNCTIONAL REQUIREMENTS - Module 2... · produce globally harmonised, generic...

INTERNATIONAL COUNCIL ON ARCHIVES

1


PRINCIPLES AND FUNCTIONAL

REQUIREMENTS

FOR RECORDS IN ELECTRONIC OFFICE ENVIRONMENTS

TRAINING IN MODULE 2

PARTICIPANTS WORKBOOK

OCTOBER 2013


2


Principles and Functional Requirements for Records in Electronic Office

Environments – Training in Module 2 – Participants Workbook, 2013, published at

www.ica.org

October 2013


3

CONTENTS

INTRODUCTION ........................................................................................................ 4 Scope .......................................................................Error! Bookmark not defined.

Audience ..................................................................Error! Bookmark not defined.

DIGITAL RECORDKEEPING ......................................Error! Bookmark not defined. What are Digital Records? .......................................Error! Bookmark not defined.

Strategies for Digital Preservation ............................Error! Bookmark not defined.

ORGANISATIONAL PROCESSES .............................Error! Bookmark not defined. Policy and Procedures .............................................Error! Bookmark not defined.

Work Process Analysis ............................................Error! Bookmark not defined.

Project Management and Planning ..........................Error! Bookmark not defined.

Appendix 1 – Risk matrix .............................................Error! Bookmark not defined.


4

INTRODUCTION

In 2008, the International Council on Archives (ICA) published three modules of its Principles and Functional Requirements for Records in Electronic Office Environments. The main aims of the project were to:

produce globally harmonised, generic principles and functional requirements for software used to create and manage electronic records in office environments;

synthesise existing jurisdiction and nationally specific work into requirements and guidelines to meet the needs of the international archival community;

enable that community to liaise, in a consolidated manner, with the global software industry; and

be consistent with the International Standard on Records Management, ISO 15489.

The project resulted in three modules, collectively known as ICA-Req, which were published in 2008. They are:

Module 1: Overview and Statement of Principles1

Module 2: Guidelines and Functional Requirements for Electronic Records Management Systems2

Module 3: Guidelines and Functional Requirements for Records in Business Systems3

Module 2 aims to support organisations in ensuring that records of business activities transacted through electronic records management systems are appropriately identified and managed by:

improving electronic recordkeeping practices;

reducing the duplication of effort and associated costs in identifying a minimum level of recordkeeping functionality for electronic records management systems; and

establishing greater standardisation of recordkeeping requirements for software vendors across different jurisdictions.

This Module articulates a set of functional requirements for electronic records management systems. These requirements apply to records irrespective of the media in which they were created and stored. They are intended to:

explain processes and requirements for identifying and managing records in electronic records management systems;

1 http://www.ica.org/sites/default/files/ICA%20Overviewprinciples%20and%20Functional%20Requirements%20Module%201.pdf 2 http://www.ica.org/sites/default/files/ICA-Guidelinesprinciples%20and%20Functional%20Requirements%20Module%202.pdf 3 http://www.ica.org/sites/default/files/ICA-Guidelines-Principles%20and%20Functional%20Requirements%20Module%203.pdf

http://www.ica.org/sites/default/files/ICA%20Overviewprinciples%20and%20Functional%20Requirements%20Module%201.pdf

http://www.ica.org/sites/default/files/ICA-Guidelinesprinciples%20and%20Functional%20Requirements%20Module%202.pdf

http://www.ica.org/sites/default/files/ICA-Guidelines-Principles%20and%20Functional%20Requirements%20Module%203.pdf


5

develop requirements for recordkeeping functionality to be included in a design specification when building, upgrading or purchasing electronic records management systems software;

inform recordkeeping functional requirements in the selection of commercially available electronic records management systems; and

review the recordkeeping functionality or assess compliance of existing electronic records management systems.

The workbook is aimed at

organisational records professionals or system procurement project leaders,;

jurisdictional standard-setters and the wider recordkeeping community; and

software vendors and developers who market and/or develop electronic records management system products. This Module is intended to inform their decision-making when designing recordkeeping functionality within electronic recordkeeping products.

You should use this workbook in conjunction with Module 2: Principles and Functional Requirements for Electronic Records Management Systems.

FUNCTIONAL REQUIREMENTS FOR RECORDS IN ELECTRONIC

RECORDS MANAGEMENT SYSTEMS

Functional requirements for records in electronic records management systems may be defined as the functionality that is required of an electronic system in order for it to meet the recordkeeping needs of an organisation. For example, from a recordkeeping perspective, an electronic records management system must be able to support a business classification scheme. ICA-Req expresses this requirement as: ‘[The electronic records management system must …] support and be compatible with the organisational classification scheme.’4

Taken together, the individual requirements make up a list which describes all of the necessary functionality. Such a list will typically form part of the specification for the system prior to procurement. In the case of a standard such as ICA-Req, the list can also be used as a checklist to gauge how well an existing system complies with the requirements and thus how appropriate recordkeeping is within the electronic records management system and the business process.

Functional requirements are usually graded according to how crucial they are to achieving the overall goals of the business system. ICA-Req has three levels: ‘must’, ‘should’ and ‘may’. These are discussed in more detail in section 0 below. It is important to differentiate between the ICA Requirements and an organisation’s own documentation, such as a system specification or an audit checklist. ICA-Req provides a comprehensive set of functionality requirements to consider when specifying a new system or auditing an existing system.

4 http://www.ica.org/sites/default/files/ICA-Guidelines-

Principles%20and%20Functional%20Requirements%20Module%203.pdf p30




6

It is important to remember that ICA-Req does not, on its own, provide a comprehensive list of business process requirements required from an electronic records management system. It focuses purely on recordkeeping requirements; the business process requirements need to be developed and specified by the IT professionals and the business team procuring the system.

WHY STANDARDS ARE IMPORTANT

In archives and recordkeeping we have a range of standards to take into consideration. This range is widened when we work with digital records. In terms of validation of standards, they fall into the following categories:

Professional standards: where a standard methodology or specification has been developed by a group of experts or professional bodies and adherence is necessary for credibility and proof of competence. An example of this is the ICA International Standard on Archival Description (ISAD-G).

National and international technical standards: these are standards developed or adopted by national and international standards authorities. The standards are drafted by teams of national or international experts and go through a rigorous approval process. An example of a national standard is the British Standard BS 5454:2000, ‘Recommendations for the storage and exhibition of archival documents’. An example of an international standard is ISO15489-1 Information and Documentation - Records Management, informally known as the International Records Management Standard. Compliance with technical standards can be a requirement to work in the field, particularly in the engineering and building professions.

De facto standards: where one product dominates the market causing compatible products to be made. Examples of de facto standards include the QWERTY keyboard and the VHS video format.

Why Use Standards?

It is good to use standards for several reasons:

they prevent the risk of re-inventing or re-developing a definition or methodology;

they define an agreed level of excellence, competency and (in some cases) safety;

they provide a benchmark against which performance can be measured;

5 Chambers 20th Century Dictionary

‘Standard:

A thing, quality or specification by which something may be tested or

measured; an established or accepted model; a definite level of excellence or

adequacy required, aimed at or possible.’5


7

they encourage consistency both within an organisation and across organisations or even national jurisdictions; and

they demonstrate professionalism, accountability and efficiency to colleagues, fellow professionals, funders and other stakeholders.

The Benefits Of Using ICA-Req

There are three other well-known functional specifications for electronic records, as follows:

MoReq2: The MoReq specification, currently in its second edition (2008), is owned by the European Commission and was developed under the aegis of the DLM Forum. It is therefore a European de facto standard. It ‘focuses mainly on functional requirements for electronic records management systems (ERMS)’6

US Department of Defence’s Electronic Records Management Software Applications Design Criteria Standard: this is the 3rd version (2007) of the US standard that is mandatory for suppliers to the American Department of Defence but optional for civilian agencies. Products are tested for compliance with this de facto standard which “defines the basic requirements … that must be met by records management application (RMA) products”7

The British National Archives’ (TNA) Requirements for Electronic Records Management Systems: this was developed to support UK Government Departments in procuring electronic document and records management (EDRM) systems. Software vendors could apply for TNA approval of their systems and the Departments had confidence that approved systems would meet recordkeeping needs. The specification, another de facto standard, dates back to 2002 and is no longer used8.

The ICA Standard aims to be an international standard and therefore applicable to any jurisdiction. Whilst the other standards are useful references, they are aimed at the European Community and at American Government bodies respectively. The UK standard is effectively defunct. Moreover, the other important difference is that the ICA Standard also addresses the issue of records that are not in dedicated EDRM systems. ICA-Req is therefore good to use because:

it is non-jurisdictional; and

it addresses all electronic records created and maintained by an organisation in any business system, not just those in EDRM systems.

6

http://www.dlmforum.eu/index.php?option=com_content&view=category&layout=blog&id=901&Itemid=78&lang=en 7 US Department of Defence’s Electronic Records Management Software Applications Design Criteria Standard

(http://jitc.fhu.disa.mil/recmgt/p50152stdapr07.pdf) 8 But it is available as an archived webpage at:

http://collections.europarchive.org/tna/20080108102455/http://www.nationalarchives.gov.uk/documents/requirementsfinal.pdf

http://collections.europarchive.org/tna/20080108102455/http:/www.nationalarchives.gov.uk/documents/requirementsfinal.pdf

http://collections.europarchive.org/tna/20080108102455/http:/www.nationalarchives.gov.uk/documents/requirementsfinal.pdf


8

USING THE FUNCTIONAL REQUIREMENTS

The functional requirements formulated in Module 2 are not meant to be used as a stand-alone requirement specification. The idea is they should be integrated into a functional user requirement specification in which both the recordkeeping requirement and the business requirements are addressed.

To enable the design of a functional user requirement specification you need to consider the following aspects.

Understand the Regulatory Framework Within Which Your Organisation Exists

Every organisation functions within a specific legislative and regulatory environment that guides the organisation regarding the specific functions it should deliver and that requires specific evidence to be created to demonstrate legal framework compliance. You need to determine how the legislative and regulatory environment affects your work activities/functions and you should determine how these activities/functions should be documented to provide adequate evidence of compliance with the legislation governing your specific work environment.

List the legislation, regulations, standards, work directives and practice notes that regulate

your work environment.

Understand the Business Of An Organisation

Understanding the business of an organisation serves a dual purpose:

a) Records are created within the business context of an organisation, and are kept

as evidence of business activities: they have an evidential purpose. Every

decision an organisation makes, and everything an organisation does, involves

the use of information. The manner in which an organisation creates, classifies,

stores and manages its records contributes to the success or failure of the

organisation. It is necessary to understand the business processes, why and

when records are generated and how they should be managed to ensure that

they do have evidential weight. An analysis of the business processes is

necessary to enable the integration of the recordkeeping requirements into the

business operations of the organisation.

The functional requirements in Module 2 only cover the minimum recordkeeping

functionality which the software should possess to enable it to perform the

recordkeeping functions in an organisation. They should not be used without

integrating them into the business requirements. Remember that the

requirements listed in Module 2 and the obligation levels assigned to them may

have to be adapted to suit your specific environment. For example, it would not

make any sense to have as a mandatory requirement that the system must allow

parts to be opened for folders in the file plan if you do not require your records to

be managed in volumes/parts.

b) When an organisation envisages the automation of its operations, business

process mapping/modelling is required before processes can be designed. The


9

processes should also be optimised and approved by the organisation to avoid

the automation of ineffective processes that would in turn prevent the creation of

authoritative records. Re-engineering the processes would contribute to the

improvement of service delivery.

List a few business processes in your environment that do not culminate in the recording of documentary evidence.

Now list a few business processes that do culminate in the recording of documentary evidence How is that evidence recorded? Where is it stored?

What do you understand by the concept ‘record’? In your own work environment, what documentary evidence that you create is considered ‘official records’ and what is not?

Understand the Records Requirements of the Organisation

Records are the reflection of an organisation’s activities and the environment in which the organisation operates. It is essential for an organisation to know which records it should be creating to enable it to conduct its business in an orderly manner, to comply with legal requirements and to mitigate risk. It is also essential for an organisation to know what records it holds to enable it to:

respond to operational demands;

respond to requests for information;

prevent access to information that should not be made available due to protection of privacy legislation.

An analysis should be done of the current recordkeeping practices. A records audit will

identify each record type, records series and system,

help to identify any problems with the current recordkeeping practices;

assist with the design of a file plan;

assist with the production of a retention schedule;

help to determine what is required to install and maintain the recordkeeping programme (space, equipment, personnel, etc).

In order to meet recordkeeping objectives and users’ needs, having regard to the likely availability of resources, a records audit needs to include the following:

what records are held and the activities to which they relate;

an inventory of record containers (cabinets, shelves, etc);

records documentation (file lists, indexes, etc);

amount of records;

where copies of records exist;

date range of the records;


10

frequency of consultation of the records;

tracking systems for the records;

current recordkeeping system and competence levels of recordkeeping staff;

recordkeeping costs;

identification of records that should be sustained for the long term.

This analysis should also assist with determining the most appropriate policies, procedures, standards and tools that are necessary to support sound recordkeeping practices.

Identify problems that your organisation experiences as a result of poor record-

keeping and provide possible solutions to resolve these problems.

Document the Business Requirements

In order to get the required results it is essential that the business requirements be clearly and comprehensively documented. This is the wish list of the organisation. If something is not in the document you cannot expect the vendor to deliver it. The vendors will use this document to develop their quotations and demonstration models. Once a vendor is appointed they will take this document and develop the functional specification. After the functional specification has been approved the technical specialists will begin to build the system in accordance with your requirements. Some negotiation can and usually does take place: however, if there are major changes or additions these can have financial implications.

The business requirements document can have various titles, such as Business Requirements Specification (BRS) or Statement of User Requirements (SOUR).

The initial step is to state exactly what current recordkeeping problems need to be solved. The problems should cover both paper and electronic records including email and other forms of communication, such as social networking, instant messaging etc. Reference to legislation and your records policy will be used as a guide. When moving to a system to manage electronic records it is important to think ahead and look at the problem as a whole. A need to reduce the use of paper should not be the only driver for implementing a new system. Some of the areas that should be analysed include the following:

How are people currently storing their business related emails?

How are people managing the electronic records they create every day? Are they printed out and filed, stored on the C-drives of their computers, stored on network drives?

How are they named and indexed? Is there any control or can each person do as they please?

Does your organisation use any of the social networks for business purposes, e.g. Facebook? If so is the information from the site managed as a record?

Use of instant messaging e.g. Skype, Communicator: if decisions are made using these technologies, how is the information captured and managed?


11

Once all the electronic recordkeeping problems have been identified, determine some desired results, e.g.

All business email must be captured as a business record.

All attachments to emails must be stored with the original email in order to maintain all metadata.

A file plan that has been designed around business functions will be used for the storage of all records

Confidentiality of certain records must be maintained

Access to electronic records must be defined.

During this process it is not necessary to have any specific electronic recordkeeping knowledge. As the business representative it is your responsibility to understand the needs of the organisation.

These needs, together with clear descriptions of the recordkeeping processes should be written into the specification which will be given to the vendor. From this document the vendor will prepare a quotation from which the purchase decisions will be made. In addition to the desired results the specification should cover recordkeeping requirements in terms of your recordkeeping policy and procedures.

All businesses and organisations are different; therefore each must develop their own list of requirements.

The following is a list suggesting headings that could be in the specification:

1. Intent What is the reason for developing this document?

2. Definitions, Abbreviations and Acronyms Clarify terms that are used in the document, so as to reduce misunderstanding.

3. Document Approval List the names and designations of the people who have developed the document and take responsibility for its content.

4. Reference Documents List all documents that have a bearing on the contents of the specification, e.g. policies, written procedures, retention schedules.

5. Business Design Principles List all requirements with an explanation if necessary, e.g.

a) Will access over a large geographic area be required? b) Is a single document repository needed or multiple repositories? c) Definition of document types d) Definition of naming conventions e) The ability to create and/or maintain document links f) Use of workflow and process automation - define the various responsibilities

throughout the processes g) Use of electronic signatures h) Use of a function based file plan


12

i) Search facility on metadata and content j) Creation of reports k) Maintenance of audit trails and history log l) Scanning or imaging solution for digitising hard copy records m) User access and control n) Migration of records from their current locations, e.g. on C drives, Network

drives, in paper o) Integration with other business systems, e.g. Human Resources System,

Financial System, email system etc.

This document will become the primary reference throughout the project. During its development it is important that all business stakeholders have an opportunity to add their input. Once the document has been finalised each of the stakeholders should sign their approval of the document.

The vendor will be bound by the document and copies should be made available to all project personnel.

Changes to the requirements may become necessary and will need to follow a controlled process. If this is the case the document/business owner will be responsible for updating the document, keeping track of version numbers and ensuring the relevant business stakeholder approves the changes.

User acceptance scripts will be written based on the requirements of this document. User Acceptance Testing will be done and the outcomes will be measured against the requirements of the specification.

Integrate Recordkeeping Into the Business Requirements

The implementation of technology never happens in isolation from the broader business and recordkeeping environment. Such implementations have an enormous impact on all the business and recordkeeping practices of an organisation. The deployment of technology solutions changes the way business is conducted and also changes the way that records are created, managed and stored.

The role of the organisation, its structure and the administrative, legal, business, regulatory and socio-political environment in which it operates are major factors affecting its business operations and concomitant recordkeeping practices.

Analysing the business requirements provides:

an understanding of the organisation and the administrative, legal, business and social contexts in which it operates;

an understanding of the business operations and the records that must be created and kept for all the business transactions;

an understanding of the organisation’s recordkeeping strengths and weaknesses;

an understanding of the records that need to be sustained over the long term;

a sound basis for defining the scope of the organisation’s recordkeeping project and presenting a business case for managerial support; and


13

information about the requirements of the body’s stakeholders.

The information gathered during such an analysis is an essential basis for the functional requirement specification that will form part of the tender specification for the new system.

Do not copy and paste the Module 2 requirements into your user requirement specification exactly as it is. Remember that they are generic recordkeeping requirements. They are not your recordkeeping requirements.

For example, look at the following requirement from Module 2:

1 Enable integration with business applications so that transactional records created by those applications can be captured within the electronic records management system.

What does this mean for your environment specifically? Make a list of the applications that you use in your environment – remember that your environment may use more than just an office suite like MS Office or Open Office – and then think about how you want these systems to integrate into the electronic records system or vice versa. What do you want the system(s) to do? List these as requirement statements.

Most of the requirements in Module 2 need to be adapted to suit your specific work environment. If you do not adapt them, you may end up with a business requirement and a recordkeeping requirement that does not ‘talk’ to each other. Such a user requirement specification may lead to your organisation to procure a fragmented system which will be very difficult to implement.

Identify more examples from Module 2 where you would need to adapt the requirements to suit your specific work environment.

Also remember that each organisation is unique and that the requirements that are mandatory in one environment may not be mandatory in another environment. For example, if your organisation does not require the use of a file plan, but requires you to use some other method of organising records, why would you then have the file plan as a mandatory requirement in your specification? If you do not approach this from a very analytical perspective and clearly state you own organisation’s requirements, the system that you procure will not be able to be implemented in your work environment

Look at the obligation levels of the requirements in Module 2. Does the obligation levels suit your specific work environment?

ASSESSING AVAILABLE SOFTWARE PRODUCTS AGAINST REQUIREMENTS

The goal of the organisation is to select a software package that best fits the business requirements defined in the business requirement specification. The aim is


14

not to implement a recordkeeping solution independent from the business requirements as this would defeat the purpose of recordkeeping as a natural result of business operations. The aim would rather be to find a solution which integrates the business requirements and the recordkeeping requirement seamlessly to such an extent that the management of records is intuitive and spontaneous rather that a forced add-on.

Any organisation that wants to procure a software solution is likely to be required to go through a formal tender process. It is recommended that the supply chain management processes be investigated and adhered to so as to ensure an open and transparent tender bidding process.

The objective of the tender process would be to evaluate:

if the software solution meets the business requirements;

if additional business benefits can be derived from the software;

if the software requires additional plug-ins or whether the software provides the functionality out-of-the-box. The more additional plug-ins required, the more expensive the software solution will be to maintain in the future, as every additional component added will require additional upgrades at a later stage;

what the hardware requirements are for the optimal usage of the software solution;

whether the supplier has the knowledge and skill as well as the required resources to implement and maintain the hardware and software infrastructure, and if not, what additional resources need to be procured;

if the initial pricing of the solution is within budget;

what the long term budget implications of the software solution would be.

It is recommended that software evaluation should be done in the following phases:

Phase 1: Evaluate the functionality of the software. The intent is in the first instance that the software solution must be able to meet the functional business requirements stipulated in the tender specification. Solutions that do not meet requirements need not be evaluated in the subsequent phases of the tender process. It would not be sufficient to evaluate the software based on a tender questionnaire only. You need to evaluate based on what the software can do, not based on what the supplier thinks you want to know what the software can do. It is therefore recommended that this phase of the evaluation consist of two sub-phases, namely:

Phase 1a) Evaluate the answers that the suppliers gave you in the tender submission. To enable you to do this, you need to know beforehand what the answers are that you expect to see. This implies that you need to know the functional requirements as well as the perceived business benefits intimately so that you can make a proper evaluation of the answers.

Phase 1b) Evaluate the software based on a show and tell by the supplier. To enable you to do this, you need to decide beforehand which functionalities in the


15

business requirement you want to see. You may also identify other requirements during the evaluation of the suppliers’ answers that you wish to see. Remember that this should be a transparent process, which means that all the software must be evaluated in the same way.

Phase 2: Evaluate the additional hardware and network requirements Ideally, the intent is that any solution should be able to use/re-use as much of the existing hardware and network infrastructure as possible. It would not make much sense to buy a solution that requires a totally new hardware and network infrastructure as this would increase the cost of the implementation exponentially. Solutions that cannot use/re-use any of the existing infrastructure may not need to be evaluated in the subsequent phases of the tender process.

Furthermore, you may have software solutions implemented already that should be able to integrate into the new solution. You need to assess beforehand if this is possible or whether you need to procure additional integration service providers to write the integration between your existing solution and the new one. Any integration solutions will add to the cost of the project and have long-term implications as the services of the integration specialist may be required each time you upgrade your software.

Think about your specific work environment.

What technology solutions do you have deployed already? Which of them would you want to use/re-use as part of your new technology implementation and why?

Phase 3: Evaluate the capacity of the supplier to implement, maintain, and sustain the solution. Software suppliers that lack the skills, knowledge and resources to implement the solution can cause great damage to your organisation. Selecting potential suppliers should be done with care as the relationship with the supplier will be a long-term investment. Many software suppliers do not have a clear understanding of recordkeeping and may need to source additional service providers to assist with the recordkeeping implementation. You need to know this beforehand as the knowledge and skills level of the additional service providers also need to be evaluated. Suppliers that do not meet requirements need not go through to the next phase of the evaluation.

How would you go about evaluating the capacity of a supplier? Make a list of questions that you would ask them. Also consider the possible answers that you would require and note them down too.

Phase 4: Evaluate the costing of the solution.

The aim of evaluating the cost of the solution is to find a solution that meets the business requirements at the most cost effective price. All organisations will be limited by what they can afford to spend on such a solution. It is extremely critical that all the financial implications of the solution be investigated thoroughly during this phase of the evaluation. You do not want to implement a solution only to realize halfway through the implementation that you need to procure additional software,


16

hardware and services to make the solution work. Your evaluation should be such that the suppliers are forced to disclose all the financial implications of the solution.

List the possible financial implications about which you would require disclosure.

Note why these are important to your organisation.

Phase 5: And now it is time to get real…don’t buy without evidence When you make a decision about the solution which you want to procure, it would be best to require the supplier to run a scenario-based pilot project for your organisation to prove that the software meets requirements. A supplier that is confident that the software would be able to meet requirements should be willing to do a scenario based pilot project without charging the organisation for this service.

Think about your own work environment.

Write a short scenario, i.e. not more than 1 page, which you could provide to the vendors to set up a test solution for you to play with.

Based on the scenario, design a checklist that you would use to evaluate whether the test solution is doing what you require it to do.

PREPARING THE ORGANISATION FOR IMPLEMENTATION

This is one of the most critical aspects of the project. Without commitment from the stakeholders the project will run a very high risk of failure.The following are the steps and activities that need to be undertaken in order to prepare the organisation for change.

Change Management

This section outlines setting the scene and preparing for the rest of the change management effort, in line with an organisation’s change management philosophy. There should be a strong focus on establishing early management awareness and involvement.

OBJECTIVES

Determine the overall model for the change management approach

Get an initial idea of who the stakeholders are

Align with management, both business and project

Understand what else is happening in the organisation, particularly other IT projects.

DELIVERABLES

a) The Case for Change This document should describe the compelling reasons for implementing EDRMS within the organisation.


17

b) Change Impact Assessment Once the impacts and stakeholder groups are identified, the change impact level should be determined.

The following table is an example of how the change impact can be determined:

Change Impact Level

Definition

High Impact

Typical for major transformations:

High complexity

Large number of stakeholders impacted

Fundamental job/context shifts expected. Large changes to an individual's responsibilities expected and new/different skills required

Significant number of new roles and jobs, including redefinition of current jobs required

Medium Impact

Typical for operational change efforts:

Some complexity

Some stakeholders impacted

Some changes to an individual's responsibilities may require additional skills

Some new roles and jobs required and/or to be redefined

Low Impact

Typical for transactional change:

Low/minimal complexity

Very few stakeholders impacted

Minimal change to an individual's responsibilities that will require few new skills

Little to no new roles or jobs required and/or to be redefined

Think about your work environment and determine the level of impact the implementation of an electronic records management system would have.


18

Once impacts are identified, identify potential solutions to mitigate the impacts. Solutions fall into categories outlined in the table below, and become part of the overall organisational change management plan:

c) Stakeholder Analysis

Stakeholder analysis will identify the different types of stakeholders and their attitudes to change. Use the stakeholder analysis as the starting point to identify a list of individuals and groups representing those who have a primary interest and involvement with the change effort. During the analysis identify the different types of stakeholders in the organisation and on the project and then determine their attitude to change and what impact that attitude will have on the project.

The following are typical types of stakeholders and their roles.

Mitigation Category

Definition

Stakeholder Engagement

Which stakeholders are impacted? How do we engage them? Which key leaders need to provide vision and direction and need to become advocates? How should they do this?

Example: Solutions include IM led team engagement meetings; workshops; Leadership Meetings; etc.

Communications

What information about the impact needs to be communicated? To whom? When? How?

Example: Solutions may include news updates via newsletters, brochures, talking points, presentations , scripted e-mails, etc.

Organisation and Job Alignment

How are the impacts changing roles and responsibilities, day to day tasks etc.?

Example: Analysis that informs the degree of need for change in roles and responsibilities, day to day tasks etc.

Learning and Performance

Support

Will the impacts require training? Who needs it? What should it cover?

Example: Focused on training stakeholders on new systems and processes, using classroom and web-based training, quick reference cards, user manuals, etc.


19

Stakeholder Type

Sponsors

Sponsors are individual decision makers who have the authority to legitimise a change effort. Sponsors have a decision-making role for critical elements of the change; they are typically leaders of highly-affected stakeholder groups.

Advocates

Advocates are individuals and/or groups who have a vested interest in the success of the change. Advocates are most interested in the realisation of expected benefits and should become well-positioned to leverage their internal influence and relationships for the project’s benefit. Advocates often act as sponsors.

Change Agents

Change agents represent the highly affected areas in the organisation. They are the people responsible for managing and reinforcing the change. Responsibilities may include shaping solutions, championing and guiding aspects of the project in the line organisation, coaching and preparing sponsors and leaders, helping prepare users and frontline staff for implementation, and managing benefits realisation.

Targets

Targets are individuals or groups who are highly affected by the change, and are, therefore, the major focus of the change effort. When uncertain about the role a person has, always treat the person as a target first.

Change Influence

High Can significantly influence driving, stopping or seriously delaying the project.

Medium Can moderately influence driving, stopping or seriously delaying the project.

Low Can minimally influence driving, stopping or seriously delaying the project.

Mindset

Aware Encounters change and realises change is imminent

Understands Accepts nature and intent of change

Adopts Tests the new concepts and change implications. Articulates willingness to perform as the change requires

Committed Articulates the change as norms and articulates his/her personal ownership of the change

Owns Change Participates in facilitating change. Changes behaviour or procedures to support process changes (post implementation)

Change Impact

High

Significant impact on frequency of work, volume of work, complexity of work, responsibilities, and/or skill and knowledge requirements. A high impact rating may be also assessed if potential new roles are created as a result of the change.

Medium

Moderate impact on the frequency of work, volume of work, complexity of work, responsibilities, and/or skill and knowledge requirements, but not a significant impact. The difference will be less significant than a ‘high impact’ rating change.

Low Minor impact on the frequency of work, volume of work, complexity of work, responsibilities, and/or skill and knowledge requirements.


20

The information gained through this analysis will inform the way in which the project team needs to communicate with the stakeholders.

Communication

OVERVIEW

Communication is the ‘hearts and minds’ aspect of the change management approach. A carefully considered communication strategy is realised through a detailed communication plan. Stakeholders are analysed and tracked over time, with pro-active interventions where progress targets are not being met or where there are issues.

OBJECTIVES

Develop, over time and to defined targets, awareness and understanding of the project and its outcomes among prioritised stakeholders (individuals and/or groups).

General awareness as required among stakeholders.

Commitment or at least full compliance among stakeholders as required.

NOTES

It is important to spend adequate time thinking about communication before moving into implementation. If this is not done, communication efforts may not contribute fully to the project objectives, or even worse, hamper the project.


21

DELIVERABLES

Elements of the Communications Strategy and Plan are listed in the table below

Communications Strategy and Plan

Source

The demand for communication will originate mainly from the

project team.

The content of the communication will be derived from

project documentation such as the project charter, business

requirements specification, meeting minutes.

The communication material (e.g. message drafts or

newsletters) will originate from the change manager working

with the formal communication channels within the

organisation, e.g. Public Relations.

All communication material will be approved by the relevant

managers.

The communication will be sent from the records

professional, business owner, or relevant manager.

Message

Objective

Outcomes expected

Achieve objective

Relevant

Voice Source Appropriate message content

Appropriate message style and tone

Content

Correct

Short

Simple

Understandable

Quality fit for purpose


22

Communications Strategy and Plan cont’d

Channel

Appropriate

Optimal format

The majority of communication should be through ‘warm’

channels i.e. people speaking and interacting in a face-to-face

setting, as these are by far the most effective, e.g.

Meetings

Workshops

Events

‘Cold’ communication channels should mainly be used to

support the ‘warm’ communication, e.g.

Portal /Intranet

Use as information repository

Drill-down detailed information

E-mail

Newsflash

Message from the Sponsor

Take Note

Please Action

Existing Channels

Internal newsletters

Quick Reference Guides

Recipients

People change when they talk, not when they listen.

Create as many opportunities as possible to listen to

stakeholders – not only does this elicit valuable information,

but the act of listening is a communication intervention in its

own right.

Keep track of stakeholders’ input.

Capture verbal feedback gained in the course of an informal

conversation

Think about your work environment and determine the groups of stakeholders that exist in your organisation. Then determine what level of communication is required for each group and the best method of delivering this information. The result of this analysis can be put into a table under the following headings: Communication Channel, Stakeholders, Communication Content, Communication Method.


23

Workforce Readiness

Training is often the largest single interface between the project and the wider stakeholder community who are directly impacted by the project. It is also usually the most direct and significant mechanism through which the project design may be translated into actual behaviour. Where training is required in a project, an effective training strategy and a well-managed training process are always critical to project success.

OBJECTIVES

Develop a training approach that supports and maximises the behavioural outcomes

Manage risks associated with limited resources and ensure effective utilisation of such resources.

Ensure an effective and efficient training process, including follow-up actions.

NOTES

The complete training process falls within the scope of change management, but not the delivery of training.

DELIVERABLES

Training Strategy

Training Needs Analysis

Role Mapping

Training Logistics

Performance Support Structures

Adoption and Sustainability

The focus is on sustainability and the establishment of a platform for continuous improvement. As the project phase draws to a close, an adoption and sustainability strategy is developed in conjunction with organisational leadership and forms part of the content of operational handover.

OBJECTIVES

Ensure sustainability.

Provide a starting point for continuous improvement activities by ensuring that the management team understands and supports the required processes and/or structures.

Identify all major organisational processes that have a bearing on the sustainability of the ‘to be’ and ensure that these are adequately addressed in an embedding strategy.

Hand over effectively and efficiently to post-project operational role players and leadership.


24

NOTES

The initial adoption and sustainability strategy and the positioning of the process falls within the scope of change management, but only up to the point of operational handover. Then it is owned by the management team.

Elements of the Adoption and Sustainability Strategy are listed in the table below:

Adoption and Sustainability

Deliverables

Adoption and sustainability approach

Support mechanism

Focus groups

Project Phase

Budget

Schedule

Scope

Quality

Involvement

Awareness

Understanding

Ability

Issues

Post Go-Live Phase

Benefit realisation

Support

Building competence

Issues

Ownership

Compliance

Continuous Improvement

Benefit realisation

Identification of opportunities

Ongoing learning

Networking

Knowledge management


25

Liaising with the vendor/integrator

Liaison with the vendor will develop and change during the life of the project and the use of the system. This is a long term relationship. Consequently, it is important to establish the terms of this relationship early on. It is important for the customer to establish the channels of communication and to maintain them at all times. EDRMS projects often fail as a result of poor communication between vendor and customer.

Liaising with the vendors starts early on in the life-cycle of your project. Consider the following:

ERDMS Acquisition Phase

Prior to deciding which EDRMS to acquire the customer should establish the following information regarding the vendor:

a) Does the vendor have sufficient technical staff to support the EDRMS once implementation is complete? Once implementation is over the customer’s staff will be responsible for the day-to-day management of the EDRMS. However when upgrades, crashes etc. occur it is important to know that the vendor has staff available to assist.

b) Who are their other customers and do they have reference sites that are similar in size and complexity to yours? If possible visit the reference sites and speak to current users of the EDRMS. A reputable vendor will be happy to share their customer lists and may arrange visits to sites. During the visits try to find out what type of relationship exists between the site and the vendor.

c) Who will be responsible for customisation of the EDRMS, if required, and for maintenance of the customisation during upgrades etc.? This can be an important point when deciding which EDRMS to acquire. Customisation can create long term problems, particularly if the vendor is not well established and may not have all the necessary technical staff to support the customisation.

d) What project methodology will be used? When establishing this, assess how their methodology fits with the project methodology used by the customer. It is essential that both the vendor and the customer have a very clear understanding regarding project methodology prior to implementation.

List a few questions that you would ask the vendors to determine their suitability to implement your solution in your work environment

At this stage the User Requirements should be clearly articulated so that the vendor knows exactly what it is that the customer wants.

EDRMS Implementation Phase

Once the decisions have been made regarding the acquisition of an EDRMS and the implementation project starts, a very close working relationship between the customer and the vendor should begin. The vendor should provide a project manager to oversee the implementation from their point of view. The customer should appoint their own project manager to work with the vendor to ensure that the


26

organisation’s interests are being protected. In addition the customer should assign a records professional full time to the project to ensure that all recordkeeping requirements are fulfilled. During implementation numerous decisions are made daily and it is essential that business representatives are part of this decision making and understand the impact of these decisions.

List the roles and responsibilities that you would assign the vendor’s project team and your own project team. Are there any overlapping responsibilities? If there are, who should be accountable?

Training

The vendor must provide technical and user training. The method and extent of training should be discussed and agreed by the customer and the vendor.

Handover And Maintenance

At this stage the records professional will start to assume the responsibilities that were previously held by the project team. The vendor should handover all manuals and training materials. At this stage a Service Level Agreement should be agreed and signed. This is the document that will define the relationship between the customer and the vendor into the future.

CONFIGURING OPTIONS

You need to have an idea of how you would want the system to be implemented. To be able to do this, you need to understand the different options and how they would impact your specific work environment.

Terms

Autonomic computing – computer systems capable of self-management.

Client server computing – is any distributed application which differentiates between service providers and service requestors.

Cloud computing – the provision of computer applications over the Internet as a service to users of a particular site. 9

Hybrid cloud – environment of multiple internal and /or external providers in which the cloud services are integrated to ease transition.

Autonomic Computing

.Like the nervous system of the human body, autonomic computing is a self-managing system. It is able to formulate solutions, in accordance with prescribed policies and processes, regularly adapt to changing circumstances, while concealing its complexity to operators and users. In a self-managing system, the personal operator defines the general policies and rules which determine the paradigms of the self-management process. There are four elements of a self-managing system:

9 http://www.macquariedictionary.com.au/naa@919FFC31761624/-

/p/dict/article_display.html?type=title&first=1&mid=3&last=3&current=1&result=1&DatabaseList=dictbigmac&query=cloud%20computing&searchType=findrank


27

Self-configuration – the automatic configuration of components

Self-healing – the automatic discovery and correction of faults

Self-optimisation – the automatic monitoring and management of resources ensuring maximum functioning in accordance with defined paradigms

Self-protection – proactive identification and protection from attacks.


Will this implementation option work in your environment?

Why or why not?

Client-Serving Computing

This computing system enables the distribution of its roles and responsibilities amongst several independent computers familiar to each other through a network. This type of system facilitates greater ease as far as maintenance is concerned, making it possible to replace, repair, upgrade and relocate servers while clients remain unaware and unaffected by the change. Furthermore, data is stored on servers which generally have better security control. The servers can also control access and resources and ensure clients on access authorised data. These systems can also ensure maximum security, as well as user-friendly interfaces. One of the drawbacks, however, is that because the information resources are distributed amongst various nodes, if one or more of those nodes does not store the information, the remaining nodes will not be able to complete the download of the data.



Why or why not?

Cloud Computing

Cloud computing provides conceptualising between computer resources and underlying technical architecture such as servers, storage and networks which facilitate convenient, on-demand network access to a shared pool of configurable computing resources. These resources provide and release the information with minimal human intervention or service provider interaction. The majority of cloud computing infrastructure consists of dependable services provided through data centres and built on servers, which appear as single access points for the computing needs for consumers.

Five characteristics of cloud computing include:

On-demand service

Broad network access

Resource pooling

Rapid elasticity


28

Measured service

Cloud computing customers do not own the physical infrastructure and thereby avoid capital expenditure by opting to rent the infrastructure from a third party provider. The services or resources are utilised as a service and only utilised resources are paid for. Other options may include purchasing the services on a subscription basis. Sharing computing power amongst multiple tenants may be more beneficial and cost effective. Servers should not be left idle as this can significantly reduce the speed of application development. However, a consequence of this approach is that overall computer usage may rise dramatically as customers do not have to engineer for peak load limits. Also, increased bandwidth enables the same response times from centralised infrastructure at other sites.

The cloud model has been challenged by privacy advocates due to the ease which the hosting companies can monitor effortlessly the communication and data stored between the user and the host company which may result in the unscrupulous provision and disclosure of unauthorised information sources. Compliance issues must be borne in mind. Furthermore, the utilisation of community or hybrid models which are more expensive but may offer more benefits should be considered. Open standards are essential to the growth of cloud computing and the open source software has formed the ground work for numerous cloud computing implementations.

Security issues and concerns surrounding cloud computing services may result in organisations being skeptical and delaying implementation. Many people believe that the rewards of cloud computing rewards outweigh its risks. Essentially services must be measured against an organisation’s legal and regulatory requirements. Recordkeeping staff should ensure employees consider records preservation when they migrate programmes and information sources to the cloud. This means that recordkeeping staff must engage in staff discussion and participate in the contract discussions with the selected service provider. Like with all other processes of recordkeeping, the configuration of data and information sources must be closely controlled throughout the lifecycle of the information to ensure it is always possible to how where the information is and in what form it is stored.10



Why or why not?

10

http://e.wikipedia.org/wiki/Automatic_computing. <accessed April 2010> http://e.wikipedia.org/wiki/Client_computing. <accessed April 2010> http://e.wikipedia.org/wiki/Cloud_computing. <accessed March 2010> http://www.federaltimes.com/article/20100323 <accessed 27 March 2010>

http://e.wikipedia.org/wiki/Automatic_computing

http://e.wikipedia.org/wiki/Client_computing

http://e.wikipedia.org/wiki/Cloud_computing

http://www.federaltimes.com/article/20100323


29

INTEGRATION OF THE EDRMS APPLICATION WITH OTHER SOFTWARE APPLICATIONS AND BUSINESS SYSTEMS IN THE ORGANISATION

When considering EDRMS integration with existing systems there are two aspects to consider:

a) Documents generated by the other software or business systems are able to be filed and stored directly into the EDRMS.

Business systems include email, financial, human resources and line function systems. Additional systems that will need to be taken into consideration are scanning and imaging systems and any other systems where a document is converted from one format to another, e.g. conversion from microfilm to electronic formats and vice versa.

An EDRMS should manage electronic records through their lifecycle – creation, use, storage and disposition - irrespective of the system generating the record. In addition the EDRMS should manage the records in such a way that they can fulfil their legal and business functions. This means that the records management system must ensure the integrity of the records and must be comprehensive. To reduce any possibility of tampering with the integrity of a record the safest method of capture is directly from the system creating the record. In order to be comprehensive all electronic records that are required for business and/or legal purposes must be managed using one method to identify, retrieve and dispose of them. The best way to achieve this is to store them all in one EDRMS.

If the EDRMS is a standalone system without any integration, manual intervention will be required to convert records from the systems that produce them into the system that will be used to store them. During this process the integrity of the record can be compromised. In addition, this is a labour intensive and expensive process when taking into consideration the cost of paper, printing, time and staff salary costs. A typical example is printing an email and then scanning it back into the EDRMS. If records are not captured at source it is difficult to ensure that the EDRMS is truly comprehensive. There is always the risk of electronic records being stored in unmanaged and insecure environments, e.g. email in an inbox, documents on a C drive or on external devices, such as flash drives or external hard drives. Should these documents be required for legal or business purposes they are often inaccessible and their integrity cannot be guaranteed. Consequently the organisation will be at risk.

b) The EDRMS application is able to integrate with and interrogate the business systems and create a record which is then stored in the EDRMS.

In some instances it may be necessary for the EDRMS to interrogate the business system in order to create a new record, and typically this would be done through the use of workflow. An example would the preparation of a Staff Leave Statistics Monthly Report. The workflow would be designed in such a way that it would access the Human Resources system, interrogate it in order to identify what leave has been taken and how much leave is still outstanding and then populate the appropriate fields in the report template. This workflow would be designed to do this every month


30

on a predetermined date. The author of the report could add other information and then file the record in the EDRMS.

Make a list of the systems that you would like to integrate into the electronic records management system, or vice versa, and note why you think the integration is necessary.

ONGOING QUALITY ASSURANCE ISSUES

Once an EDRMS has been implemented and handed over to the customer it is important that the decisions made during implementation are supported. To ensure that this happens, policies and procedures need to be written, approved and implemented. The following are some of the polices that might be required by an organisation:

Records Management Policy

Email management Policy

Risk Management Policy

Information Management Policy

Information Security Policy

Procedures to support each of the policies will need to be written and regularly reviewed. The following are some of the recordkeeping procedures that might be required by an organisation:

Records classification

Records storage

Records access and security

Records retention and destruction

Records held

Recordkeeping change control

Vital records management

Records Management disaster preparedness

Physical records management – Registry management

Recordkeeping audit

During implementation of an EDRMS the file plan or business classification would have been developed and built into the system. Changes and additions to the file plan will be made through the change control procedure. The records professional will need to regularly monitor and approve changes and ensure that they comply with the overall design philosophy of the file plan/business classification.

Management of access control, security, confidentiality and information sensitivity within EDRMS requires regular monitoring. Access control is the overall control mechanism that is used to protect the records. It is also the mechanism that gives


31

certain people or groups of people the right to create and/or destroy records. As people move within the organisation or leave or join, access rights will need to change. The records professional will need to ensure that at all times, access control rights support the needs of the organisation. If access rights are not carefully monitored and controlled serious breaches of security are possible.

Make a list of the different roles in your organisation. What access do you think they should be provided in the system? Who should be able to read/view, edit, etc?

Retention and destruction should be controlled through a procedure. These rights should be limited to very few people. If retention schedules are not already in place they will need to be developed, approved and assigned to the relevant levels within the file plan/business classification. The records professional will be responsible for authorising all retention and destruction.

The EDRMS and all relevant policies and procedures should be regularly audited. The EDRMS should regularly produce management reports that provide information that will support the business. The following are some of the reports that an organisation might require:

Audit trail on sensitive or confidential files and/or records

Audit trail of access rights

File destruction reports

o Files/folders due for destruction

o Files/folders that have been destroyed

File archived reports

o Files/folders due for archiving

o Files/folders that have been archived, including the archive location

EDRMS usage:

o The number of records being filed during a defined period and/or in specified files/folders.

o Statistics regarding use by members of staff.

An important aspect of on-going quality control is to ensure that all users of the EDRMS are trained and aware of their responsibilities. New members of staff should be trained as soon as possible after they join the organisation to ensure compliance with the policies and procedures.

Make a list of what aspect you would like to review and how often. Also consider which other stakeholders’ input you would require to enable the review.


32

IMPLEMENTING TRAINING

Changing Attitudes

Every employee in an organisation creates and stores electronic records in a different way. By using individual logic, each person will use personal working methods to create and store information; it is this individual logic that leads to an unstructured information management system. From a recordkeeping perspective, this manner of working makes the management of electronic records very complicated. Another aspect that complicates the management of records is that employees have a perception of ownership over the records that they create and store electronically and they do not necessarily perceive the records to be official. A common logic of manipulating and accessing information is the key to success, not only in managing records but the change management process as well.

Records professionals know how important it is to manage electronic records. Employees do not necessarily know, or care, that the records should be managed properly to ensure that they are authentic and reliable evidence of transactions.

Overcoming employee perceptions about recordkeeping may be the toughest challenge for the records professional. Records professionals need to plan how to involve employees in recordkeeping activities. This is especially important in the electronic environment.

Early involvement of the staff in the process of changeover to a new system will go a long way in ensuring that awareness is created of the importance of effective recordkeeping. It is critical that records professionals provide employees with information about how the system fits into the organisation’s vision, mission and service delivery demands. Employees will need to learn different tasks or will have to take on increased responsibility for creating and filing records according to standard practice. Records professionals should consider that different employees have different roles and responsibilities and that these roles and responsibilities have different requirements for use of the system. This in turn creates different perceptions and expectations of the new system which should be managed properly.

Electronic recordkeeping projects inevitably result in changes in the way organisations work. The ability of the organisation to manage these changes will often determine the success of the implementation process.

Identify the different roles and responsibilities of employees. Consider what their specific requirements would be regarding the system.

Create a requirements matrix with the information gathered.

It is critically important that there is regular communication with the employees during the planning and implementation of the new system. It is essential to ensure that information about organisational change is disseminated effectively and comprehensively. Good communication will prevent a perception that change will be forced on the staff without listening to their concerns.


33

Keep in mind that different people react differently to change and that people express fear in different ways. Also keep in mind that different people may have different expectations that should be managed to ensure a successful implementation.

Records professionals need to be able to communicate a different message to different roles in the organisation to ensure that the communication message has maximum impact.

Consider how you would communicate with the employees. Do you know what their expectations are? What will you communicate to them to meet their expectations?

Update the requirements matrix with expectations Indicate what your communication message would be and how you would convey the message.

Training Approaches

Records professionals implementing a new system should consider that people have different learning styles and that different roles may have different requirements from training. This means that a one size fits all approach to training may not be the best way to approach the development of training material and training programmes.

Consider for instance that senior managers, besides being trained to use the system, may also have to make decisions about implementation strategies, priorities for action or resource allocation. They would therefore need to acquire an understanding of the broader issues involved with the introduction of the new system.

Consider also that users of a new system need to understand basic recordkeeping principles and practices before they are exposed to technology training. Without an awareness of the rationale and benefit to them of recordkeeping, they may never become enthusiastic users. The employees therefore may need to be trained in the following before they receive technology specific training:

how to read and use the file plan

understanding good filing practices, and

basic records maintenance procedures, including use of disposition schedules in an electronic environment and the use of email systems.

Consider furthermore that records professionals will also need to be trained in operating and configuring the system, not only how to use the system.

Also consider that proper planned training sessions will ensure efficient training delivery sessions and enhance the perception of recordkeeping as a positive and welcome change for an organisation.

Consider what the training requirements would be for each set of operational role players in your work environment.


34

Change management and training should be an active and dynamic process. Regular monitoring, evaluation, and performance measurement, feedback from users and communication is important to determine the success of the training and change management efforts as any problems with these may have a very negative impact on the continued use of the new system. Consider incentivising project milestones and rewarding groups of individuals for effort and achieving change over phases.

TROUBLESHOOTING

Troubleshooting is the term that is used to describe the process of solving system or process related problems.

When implementing a new system or operating an existing system, one expects it to behave in a certain way to achieve specific results. Any unexpected or undesirable behaviour is a symptom. Troubleshooting is the process of isolating the specific cause or causes of the symptom and to resolve the causes so that the unexpected behaviour does not re-occur.

Troubleshooting is generally done by IT staff and generally consists of three steps.

Investigating the problem

o What is the problem? Draft a clear, concise statement of the problem.

o What are the symptoms? What works? What doesn't?

o For how long has the unexpected behaviour been a problem? What has changed recently?

Analysis

o What might have caused the problem?

o Which is the most likely cause of the problem?

o How can it be fixed?

o Perform a test to see if the fix resolves the problem

o If the fix does not resolve the problem, re-do the analysis phase with the other likely causes until the desired result is achieved.

Implementation

o Complete the repair and implement the fix in all other environments which experienced the same behavioural problems

o Run a system test to see if the problem has really been fixed

o Create a record of the problem and the fix and obtain a sign-off from the system owner.

When troubleshooting the electronic recordkeeping implementation, remember to verify that the resulting behaviour is still in line with your original user requirement specification.


35

Sometimes, however, the problem is not caused by the system, but rather by the users of the system. Human behaviour has a lot to do with the success or failure of an electronic implementation. This is the reason why so much emphasis is placed on obtaining buy-in and doing change management. Mostly when the behavioural problem is caused by human factors, one can follow the same steps to try to resolve the problem.

What would you do if the staff refuses to file records into the electronic file plan? Describe how you would go about finding out what the problem is and how you would resolve the problem.

POST IMPLEMENTATION REVIEW

The purpose of a post implementation review is to ensure sustainability (See also paragraph 0) by

measuring the effectiveness of the system after it has been implemented (Does the system achieve what it is supposed to achieve?)

identifying and take corrective action (Why is it not achieving what it should and what can be done to ensure that it meets the original objective?)

evaluating the efficiency of the system development process and implementation (Can it work more efficiently, faster or better?)

establishing and implement an ongoing monitoring regime for the duration of the system.

A project has involved time, money, staff and goodwill – your organisation’s resources. Therefore, it is necessary to demonstrate that the implementation was done efficiently and that the system is achieving its objectives. A post-implementation review can provide such assurance, as it is a structured and documented investigation which serves as objective proof that your system is achieving its goals.

As outlined in Records Management Part 2: Guidelines ISO 15489.1-2002, a post implementation review is a formal process that measures results against expected outcomes so that any necessary adjustments can be made.

The following should be reviewed:

appropriateness

o appropriateness of solution compared to the organisation's needs

o objectives compared with available resources, and

o comparison of need now with original need.

effectiveness

o original objectives compared with outcomes (what was desired and what was achieved)

o outcomes compared with needs


36

o outcomes compared with standards

o present outcomes compared with past outcomes, and

o comparison between target groups within the organisation.

efficiency

o current costs compared with past costs (people, processes, technology and tools)

o costs compared with similar systems elsewhere (benchmarking), and

o extent of implementation compared with targets.

Areas can be evaluated using the following sample questions.-

a) Records creation and retrieval

Are records being created to adequately document the organisation's business activity?

Are records being captured into appropriate systems in a timely, accurate and complete manner?

Are records adequately preserved and accessible?

Can users retrieve the records they need?

Can users easily locate the records they need using the new system?

Does the organisation’s business classification scheme and thesaurus adequately reflect functions, activities and transactions?

b) Management

Is systems documentation adequate for operational and maintenance purposes?

Have audit trails been established between the old and new systems?

Have vital records and relevant control information from the old system been converted to the new system?

Are staff still relying on unauthorised stand-alone or ad hoc systems in preference to the new system(s)?

Are adequate security arrangements in place to protect sensitive records (taking into account privacy and confidentiality)?

Is the physical security of records adequate (e.g. locked cabinets, compactus)?

Has the quality and level of records-based services changed since implementation from both the user and management perspective (e.g. ease of use, precision and coverage of search and retrieval)?

How often are maintenance checks carried out?

Has the disaster response plan been tested?


37

c) Disposition

Does the organisation have comprehensive records disposition coverage?

Does the coverage satisfy the needs of the organisation?

Is it consistent with requirements appropriate to your jurisdiction?

Are the retention periods sufficient to fulfill business, accountability and societal requirements, or do they need to be revised to longer or shorter periods?

Are records being sentenced and disposed of appropriately?

Is there documentation to substantiate these actions (e.g. certificates of destruction, retention of control records, current disposition authorities)?

Is the organisation creating any additional types of records that need to be appraised and incorporated in its disposition coverage?

Are some of the vital records listed no longer being created?

d) Staff training

Are personnel aware of their recordkeeping roles and responsibilities (e.g. through job descriptions, training)?

Do personnel have access to up-to-date policy and procedural documentation?

What problems have personnel experienced with the new system?

Are personnel applying classification and titling conventions appropriately and consistently?

Are personnel retrieving records using the appropriate tools?

e) Learning from the process

Were the original terms of reference sufficiently precise to guide the project?

Did we negotiate for sufficient resources to carry out the project?

Did we keep the key stakeholders informed and committed during the project?

Could we improve our broad planning processes if we had to start afresh?

Was the planning process appropriate to the project’s size, complexity and predictability?

Did our techniques for managing the project work well?

Are the stakeholders satisfied?

Did we complete the project on time?

Did we complete the project within budget?

Have we handed the project over as a going concern?

Do we need a formal sign-off?


38

Have we acknowledged everyone who made a contribution?

Have we celebrated our success as a team (and as an organisation)?

These questions are by no means the only ones that you should ask. The specific environment and the objectives in the user requirement specification will provide additional guidance pertaining to the questions that will be relevant to you specific implementation.

Your post implementation review should culminate in a strategy for on-going review of the implementation to ensure that it remains aligned with your business objectives.

DEALING WITH UPGRADES AND UPDATES TO THE SOFTWARE

Updates and upgrades to the system, whether they are as a result of new releases by the developers such as the release of software patches, or whether they are made internally to introduce enhancements to functionality, should be managed systematically.

In co-operation with the IT unit, you need to implement a change control procedure. The change control procedure will allow anyone to request a system and/or process change, but will limit the access to make changes to specific authorised individuals. The change control procedure will also assign specific individuals the responsibility to evaluate, reject or approve, introduce and control the implementation of those changes with minimum disruption to the service provided.

Normally an in-house system administrator will, after receiving substantial training, be allowed to access the tools for customising the system by amending screen layouts or amending system parameters. If the changes require more complex changes, these changes will be done by the system supplier as part of a Service Level Agreement.

Keep in mind that changes made in one part of the system often affects other parts of the system. This is why a formal process is required to enable detailed documentation to be created of every change. This will allow the changes to be reversed should they adversely affect other parts of the system. All changes should be thoroughly tested for unexpected consequences before they are made live. All users should, therefore, fully understand the complexities involved in resolving problems and controlling change. Should your organisation plan to take full responsibility for all system changes and customisations, it is especially critical that a strict software source code change control procedures are established.

Think about your own environment.

Who would be assigned responsibility for making changes to the system?

How should change requests be submitted to that person?

Who should approve the change requests?

Describe how the change control process will work in your environment and design a change request form.


39


40

PRINCIPLES AND FUNCTIONAL REQUIREMENTS - Module 2... · produce globally harmonised, generic...

Documents

Transcript of PRINCIPLES AND FUNCTIONAL REQUIREMENTS - Module 2... · produce globally harmonised, generic...