Designing a recordkeeping system
- Steps in recordkeeping system design
- Principles of recordkeeping system design
- Recordkeeping system design may require a mix of skills
- Managing recordkeeping system design
- Documenting recordkeeping system design
System design in Step F is concerned with implementing strategies you identified in Step E, to help you build systems that meet your recordkeeping requirements. System design is therefore based around implementing the Step E strategies:
- standards, and
Your work in this step will involve designing or structuring all components of your system so that it:
- is useable and understood by staff
- accommodates all recordkeeping tools it needs to support
- is sustained by adequate policy and procedure, and
- is technically adequate and has the necessary functionality to support recordkeeping requirements.
When you have designed a system that meets all these requirements, you will have established an effective recordkeeping system for your organisation.
Tip: See system design in the context of the organisation and its requirements
The DIRKS methodology is intended to be a very scalable and flexible one. See system design in the context of your own organisation and its requirements and develop a design strategy that is appropriate to these. You do not need to develop all system components listed in this step - keep your focus based on the research you have done, the specific requirements you have identified and the strategies you've selected in the previous steps of the DIRKS methodology.
Throughout the system design activities you will undertake in this step, it is important to bear two key principles in mind:
- taking an iterative approach, and
- involving users in the process.
This approach will break your system design approach down into the following activities:
- design a bit of the system (eg a new procedure, a training package, a piece of software, a paper-based template, or a screen interface)
- test it against the requirements, deficiencies and strategies documented during steps C to E
- review it with users and other stakeholders
- depending on the outcome of the review, either redesign that bit of the system to better meet recordkeeping requirements and incorporate user feedback, or modify the requirement if it is inconsistent with user needs or recordkeeping requirements or infeasible, and
- document any changes to the design or the requirements, indicating reasons for the change, and the authority under which the change was made.
The extent to which you can involve users and take an iterative approach during the design phase will depend on time and cost constraints. However, adopting such practices will help ensure that:
- a useful, viable system is developed
- users develop a sense of system ownership through their involvement, and
- users understand the system and use it as it is intended to be used.
Tip: Remember the importance of useability, integration and the long term maintenance of records
When designing your system, remember to not underestimate the importance of system useability. Many recordkeeping systems have good capacities to create and capture records, but useability is often overlooked. The effectiveness of your system will come down to its ability to be used for a variety of purposes, and for the information it contains to be extracted and utilised. Ensure that this requirement is key among your design considerations.
When considering your recordkeeping system design, it is also important to bear system integration in mind. If you are developing a new technical application to support better recordkeeping, you will need to ensure that this integrates well with other systems currently in place in your organisation.
Remember too that some records in the system you are designing will need to be kept for long periods of time. Consider any such long term requirements during your system design phase. You may have already decided in Step E: identification of strategies for recordkeeping to use technical standards as a means of improving the long term accessibility of your records, but it is worth considering your longer term requirements at other points through the system design process.
For example, you may want to consider at the outset the system migration strategies that are necessary to sustain the records in the system and the strategies that will be necessary to sustain the security or other management controls that you apply in the system. If you are managing records that will become State archives, you will also need to design means by which
System design involves recordkeeping professionals and other experts working with users to produce specifications that best meet:
- recordkeeping requirements (identified needs to create, capture, maintain and dispose of records)
- organisational technical, economic and cultural constraints, and
- user requirements.
Given that in the contemporary business environment many business activities are conducted electronically, your system design initiatives may require significant IT involvement to ensure that the technical components of systems are adequately designed and implemented, to ensure you are able to meet your recordkeeping requirements.
Tip: Do not use jargon
Do not forget that if you are employing additional staff members to undertake system design and development and if these staff are unfamiliar with recordkeeping words and concepts, you will need to provide these staff with a good overview of your project and its recommendations to date. Particularly, make sure all staff understand the recordkeeping 'language' you use. Quite a bit of this terminology may be confusing to other staff or they may misinterpret its meaning. Providing a clear, concise overview will help to avoid any such confusion.
Example: Communicate well with IT colleagues
Be sure to communicate your ideas and requirements clearly to IT colleagues, as their support is crucial to any design projects you may want to undertake. Inadequate systems contributed to the Jamaican banking collapse in the late 1990s and inadequate communication with IT staff meant problems were not rectified when they should have been:
One respondent observed that, having identified the need for a different view of the bank’s accounting information, managers experienced difficulties in negotiating the necessary systems changes with information technology staff. Interview subjects suggested that information technology experts’ own assumptions about the significance and meaning and the information being requested made them reluctant to make systems changes. In other words, they simply did not share line management's understanding of why this information should be needed for accountability purposes.  Clear discussions with your IT staff will enable all parties to understand project requirements and constraints and will contribute to the better development or redevelopment of systems.
At this stage of your project, your DIRKS work may become a multi-team initiative, with staff from IT, training and other areas participating. If you are in this situation, be aware that unanticipated delays and changes may affect your project, as a result of the larger numbers of staff and potentially consultants involved. Other staff will have competing demands and requirements and these may affect your project timetables.
Example: Reliance on partners
The University of Indiana which undertook a major multi system assessment project noted that:
In almost every initiative undertaken in this project, we were relying on other partners to meet their obligations and maintain the original timetable. We simply could not control our own fate in the same way one can in a processing or scanning project. 
Try to be flexible, but also stress your own project's specific timeframes and deliverables. Talk to other project staff about the importance of your work and the importance to the organisation of having it completed.
In Step F you are designing your new or revised system. As you progress with its development, you need to fully document the decisions you are making and the type of system you are designing.
In Step F, some of your documentation will be created as a part of completing the step - for example drafting a policy or developing a training implementation plan. You will also need to create other documentation, such as decisions made about the logical structure of your technical components or revised work processes.
If you do take an iterative, consultative approach to your system design, be sure to fully document any changes to requirements and design components that arise from your consultation.
Creating documentation of recordkeeping system policies, procedures and practices as well as the documentation of the system implementation process is good business practice. It is also a requirement for certification against the ISO 9000 quality standards.
 Victoria L Lemieux, 'Let the Ghosts Speak: An Empirical Exploration of the 'Nature' of the Record, Archivaria, Number 51, Spring 2001, 106-107
 Philip C. Bantin, Indiana University Electronic Records Project, Phase II, 2000-2002 - Final Report to the National Historical Publications and Records Commission, Bloomington Indiana, 2002. Accessed via the Indiana University Web site in January 2003 at: http://www.libraries.iub.edu/index.php?pageId=3313