SAGESSE VOLUME VII WINTER 2022 – AN ARMA CANADA PUBLICATION

by Tod Chernikoff, CRM, IGP, CIP

 

Back to Sagesse 2022

 

Abstract

There is frequently a gap between those who buy or develop information management systems and compliance with records and information management requirements. To bridge that gap an organization’s records and information management staff must be involved in the Software Development Lifecycle process from the beginning to ensure those systems properly manage records and information across its lifecycle.

Introduction

Your records and information management (RIM) team is a critical partner and must be involved in the software development lifecycle (SDLC) process from the earliest stages to ensure that systems properly manage information assets across the information lifecycle.  By understanding the importance of making sure the systems used to process and manage information assets are created and configured to properly retain and disposition records and information you will further your organization’s capabilities around records and information management.  RIM involvement is critical to the proper development and implementation of systems, or products as some organizations call them, for a variation of reasons. First, it ensures that an organization’s records that are stored in a system are retained and dispositioned in accordance with the organization’s records retention schedule. Next, it ensures that the system can prevent the destruction or deletion of records that are required to be retained to satisfy legal, administrative, or investigative holds that are placed upon those records, or other information in the system. It also can help to support the characteristics of authoritative records per ISO 15489.

There are a few key points to consider, especially since whatever type of organization you work for, or with, there will be variations in how the SDLC process operates. SDLC refers to a process or framework within an organization that produces software through a structured flow of phases with defined tasks within each of those steps.

Systems are developed and implemented typically in a project-centric process. On the other hand, RIM is and ongoing program with your organization. This is something staff in other parts of the organization may not understand, and it also impacts how RIM staff approaches their work across the organization.

As part of the SDLC process, your RIM program must build, maintain, and update, as needed, a framework to provide current requirements information and manage your part of the review process. This process should be built so no matter who on the RIM team is working with a project team, the process and messaging is the same from team member to team member.

Where systems are not able to adequately manage and disposition records and information, your process should enable examination of these situations and grant exceptions and/or suggest workarounds.

All organizations are not built with the same capabilities. What works in one may not translate well to others. Be prepared to create a process that works for your situation.

That said, what I’d like to pass on to you in this article is that: 

1. Your RIM program staff is a critical part of the SDLC process and must be involved from the earliest stages of that process in all projects, even if it to say no records are involved and the project can move along without further RIM review
2. There will be give and take in the process
3. Systems are typically developed and implemented in a project-centric process. On the other hand, RIM is and ongoing program with your organization
4. You need to make additional considerations if you are moving a paper-based or physical process into a digital space. In some cases, this may be simpler than upgrading certain digital processes
5. As part of the SDLC process, your RIM program must build, maintain, and update, as needed, a framework to provide current requirements information and manage your part of the review process. This process should be built so no matter who on the RIM team is working with a project the process and messaging is the same from team member to team member
6. Where systems are not able to adequately manage and disposition records and information your process should enable examination of these situations and grant exceptions and/or suggest workarounds
7. All organizations are not built with the same capabilities. What works in one may not translate well to others. Be prepared to create a process that works for your situation

Software Development Methodologies

Not all systems are created or developed the same way. The two main systems development methodologies are waterfall and agile.

Waterfall methodology is a linear, sequential method with set deliverables where stakeholders provide requirements up front, and the project is planned to accommodate those requirements. Even within waterfall there are different ways to accommodate the process. The first two columns of Figure 1 show two similar, yet slightly different paths and how I compare them.

Agile development is centred around an iterative process where requirements and solutions evolve over time in a collaborative manner using cross-functional teams. This discussion will centre more on the waterfall methodology, but we cannot forget that in some organizations agile is the dominant methodology used. I work in an organization where we use both, and the volume of project using agile is growing.

Figure 1 depicts three possible development methods and how they compare to one another. The first column indicates the method that will be discussed later in this article, I have encountered this method in the private sector. The seconds column depicts the Enterprise Performance Lifecycle (EPLC) Framework. I have encountered this method while working as a consultant with a United States government agency. EPLC and SDLC ae both forms of waterfall methodology. The third column depicts an Agile development framework.  In some instances, there are similar phase names, aspects, and activities in multiple examples of the methodologies. They are aligned to depict their similarities as best as possible.

SDLC	EPLC	Agile Framework
Origination	Initiation	Initiate
Origination	Concept	Initiate
Planning	Planning	Planning
System Analysis	Requirements Analysis	Planning
System Design	Design	Planning
System Development	Development	Development
System Testing	Test	Development
User Acceptance	Test	Development
Deploy	Implementation	Deploy
Project Closeout	Operations and Maintenance	Close
	Disposition
Figure 1 Comparison of systems development methodologies

Experience and Realization of the Problem of a Disconnection

My experiences, even before becoming involved in RIM on a full-time basis, or even leaning about the SDLC, touched on aspects of information technology (IT) such as data quality and cleansing, along with user experience, requirements analysis and attending meetings, as an observer, where upper-level managers conducted reviews and made determinations regarding IT projects. Looking at these experiences some 20 plus years ago I was, without knowing it, being prepared for what was to come. I would recommend keeping your eyes open for any opportunity that might allow you to become involved in processes your organization may undertake that would allow you to expand your knowledge, skills and abilities.  These could include opportunities to be involved in projects to bring new tools and technologies onboard such as volunteering to test new tools prior to, or during, their deployment, take training on new tools being implemented or considered for implementation.

About this time 20 years ago, I began to see that there was a frequent disconnect between those who bought and built information management systems and compliance with RIM requirements. Now I spend great deal of my time on the job making that connection. Hardly a workday goes by that I don’t attend a meeting or speak with, email, or message a project manager, a requirements analyst, or a member of a business group involved in one of a thousand or so systems across the global enterprise of my employer. I also spend time at work providing various stakeholders both inside and outside in the information services department an education on this topic.

Roles

There are many people in many roles you can encountered across your organization as part of the SDLC process. 

As part of the RIM program staff your team will be headed by your organization’s RIM or Information Governance (IG) manager, director, or similarly titled leader and will include RIM and/or IG staff based on the functions performed by the team. You will likely at one time, or another, interact with your organization’s groups or departments such as:

• Legal or general counsel 
• Compliance
• Contracts, procurement, and/or vendor management 
• Business or functional groups that in many cases will be the owners of the systems being developed, including their leadership teams 
• Information technology/services groups that act in the capacity of systems and infrastructure operations teams
• Various review teams, committees, and task forces
• Various contractors and vendors
• End users
• Project or system development teams including: 
  • Project managers
  • Solutions architects
  • Enterprise architects
  • Requirements analysts
  • Testers, trainers
  • Communications specialists
  • Change management specialists
• And finally, senior managers who in all likelihood control a great deal of the power and funding within the organization.

Those Responsible, Accountable, Consulted, and Informed (raci)

To document the level of involvement of the various groups across the SDLC process, or other processes within organizations, many use what is known as a RACI chart. RACI stands for Responsible-Accountable-Consulted-Informed. The responsible party is one that initiates and performs the work to achieve the task. In addition, they are responsible for obtaining the appliable approvals. The accountable party is ultimately accountable for the completion of the task. There is only one accountable party for each task. Consulted parties are those who opinions are sought and asked to assist in completing the task. A great deal of project time goes into two way communication with consulted parties.  Informed parties are those who are kept abreast of project progress through one way communication.  The abbreviated chart in Figure 2 indicates across the top the various components within a business or public agency, and the tasks within each development phase down the left side for a generic, fictitious project. In this representation involving the waterfall methodology, the RIM program is shown on the far right. In this representation the RIM team is informed about projects’ business cases in the Origination Phase and consulted on the business requirements and so on. Within Figure 1, an “R” Indicates the responsible parties for a task, an “A” indicates the accountable party for a task, a “C” indicates the parties that are consulted, and an “I” indicates those parties that are informed about a task’s progress.

If your organization uses both waterfall and agile methodologies separate RACIs would be produced for the different methods.

	Application Management	Information Architecture	Business	Communications	RIM
Origination
Business Case		C / I	A / C		I
Business Requirements	C	C / I	A / C		C
Planning
Requirements Approach		C	C		I
System Analysis
Systems Requirements	C / I	C			C
System Design
Design Package	C / I	R / C / I	C	I	I
System Development
Test Plan	I	I	I		C
System Testing
Test Results	I	C / I	C / I	I	I
User Acceptance
Implementation Plan	C / I	C	C / I	C / I	I
Deploy
Handoff	I	I	I	I	I
Project Closeout
Lessons Learned	C	C	C	C	C
Figure 2 Example of a SDLC methodology RACI chart

High Level RIM Requirements

It is important that the RIM program make known to the development and business communities within the organization the various RIM requirements and details behind each set of requirements. Systems should be able to, for example: 

• Place holds on records and information needed for litigation, investigation or similar purposes and release those holds (and allow their legal hold function to be utilized via API)
• Associate records with retention periods and retain records in accordance with those periods
• Support records maintaining their integrity, authenticity, reliability and, usability as called for in ISO 15489
• Dispose of records and information in a manner that is properly documented and renders them unrecoverable
• Allow for searching and retrieving records; Provide needed metrics and reporting capabilities
• Help transition legacy record from old repositories to new ones for proper maintenance and disposition.

The RIM program should also make available additional information that will enable businesses, project teams and others involved to properly communicate how they will comply with these requirements within the various artifacts or documents produced along the path of the SDLC.

What May be Out of Scope

As mentioned earlier, there are situations where RIM team is not likely to be involved with projects or products being developed or deployed. Below are examples of types of systems that are frequently out of scope since data or records are typically not stored within these systems for an extended period.

1. Gateway systems receive data, and then immediately moves the data into another appropriate system for action, or for storage within a data warehouse. An example of a gateway system might be an organization’s firewall system.
2. Infrastructure systems are designed for an IT network that automates business processes at an enterprise level. An example of an organization’s infrastructure system might be Microsoft Office productivity applications such as Word or Excel.
3. Interface control systems are designed to facilitate communications between other varied data systems, so that they can quite simply “talk” to each other. An example of an organization’s interface control system might be a Temporary Storage Data (TSD) interface.
4. Search systems are designed to provide regular or ad hoc search capabilities into other systems’ data, or other data warehouses’ data. An example of an organization’s search system might be a tool such as Splunk.
5. Transactional systems receive data for review, and then moves the data to another transactional system for further review, or a data warehouse if no review is necessary. Data may remain stored indefinitely on the transactional system while the data is still under review. An example of an organization’s transactional system might be the system used by tellers, or member/customer service representatives in a financial institution.

Process Alignment – Waterfall

As depicted in Figure 1 above, the SDLC process being shown in this article is divided into nine distinct phases arranged in a linear, sequential approach. Below each section will be described as well as the basic responsibilities of an example project team and the responsibilities of the RIM team.

Origination

In the Origination Phase the main objective is to create a flow of information and understanding on the part of each team. The project team, say for example a team working to migrate an organization’s email application from and older on-premises system to a newer, cloud-based system such as Outlook within Microsoft 365 for business, needs to understand the associated RIM requirements and processes the RIM team uses to review the project. On the other hand, the RIM team, say made up of a RIM Manager as well as RIM Analysts and technical resources, needs to understand the purpose of the business process and proposed system as well as any associated business needs. This is a time in the SDLC where an opportunity exists to air the many questions and requests for information that will surely come up from both teams.

Planning

In the planning phase the project team ensures that RIM team becomes fully engaged as a stakeholder and remains a stakeholder for the duration of the project. If there is some form of mismatch between the business requirements and the RIM requirements, such as the records retention schedule does not reflect a valid business retention need over and above the legal or regulatory requirements, an update to the schedule may be in order and that the Business member(s) of the project team needs to work within their department to begin the process to request that update as soon as possible. In this phase of the SDLC, the RIM team will participate in the project kick-off and continue to ensure its understanding of the project and upcoming activities

System Analysis

In the system analysis phase, the project team will fully document the records, information, and data that the system will capture, process and store, as well as integrate the RIM requirements into the overall systems requirements and associated documentation.  

This process can be simplified if, for example, the RIM team has created supplements to the business requirements documentation package that provide guidelines or guidance indicating a detailed view of the requirements highlighted above in the discussion of the High-Level RIM Requirements. If you are familiar with US Government software standards such as DoD 5015 or NARA’s Universal Electronic Records Management Requirements these are examples of what that might look like. 

Meanwhile, the RIM team will delve more deeply into the associated business processes and the business requirements as well as gain an understanding of the records, information, and data the system will be dealing with and begin to advice the project team on any issues arising that might complicate RIM or compliance issues.

System Design

In the system design phase, the project team creates the technical solution architecture that includes the tools and methods that will execute on the applicable RIM requirements. The project team also consults with the RIM team as needed to answer any outstanding questions and creates testing plans that reflect the RIM requirements.  

At this point in the development process the RIM team will be continuing to review project information as conditions evolve and make any adjustments in its advice as needed. They will also be providing input to and reviewing the testing and communications plans.

System Development

In the system development phase, the project team will ensure the system being built includes the RIM-related features and requirements as specified in the system and design requirements documentation. Beyond the build, the system will be properly configured and integrated with other systems as it has been designed to work with. 

Meanwhile, the RIM team will continue to address any questions or issues that arise and will prepare any information or data needed for the System Testing phase.

System Testing

In the system testing phase, the project team conducts testing of the developed system, including the RIM related components and integration points using the information, data and requirements provided by the RIM team and provides the results to the RIM team who will review them and provide appropriate feedback.  In this phase, the RIM team will also be reviewing the training materials and support documentation and provide feedback on them as needed.

User Acceptance

In the user acceptance phase the project team will ensure that any RIM related issues uncovered during the System Testing process have been resolved, conduct user testing of the RIM components and integration points, and resolve those issues to the satisfaction of the RIM team prior to deployment. 

The RIM team will determine if the RIM components and integration points are ready for deployment based on the results of the user testing and any follow up actions deemed necessary and will review and provide any necessary updates for the RIM related training materials and support documentation.

Deployment

At the point in time the system reaches deployment the project team places the system into production for the end users and begins to provide on-going support and maintenance of the system. 

During this phase of the project, the RIM team will assume, if any exists, responsibilities related to the RIM program and over time provides applicable updates to RIM configurations, as needed.

Closeout

As the project closeout phase occurs, the project team will transfer any applicable RIM related responsibilities and retain and disposition applicable system documentation per the records schedule. Finally, the RIM team will provide any applicable assistance with existing or ongoing RIM related issues and provide any input to the lessons learned documentation.

Process Alignment – Agile

Although the focus of this article is the process alignment of the waterfall methodology, I will take a brief opportunity to look at the five phases and associated responsibilities for projects using an agile development methodology. 

As this is an iterative method – it does not follow a strictly linear path. Agile is beyond a methodology – it is a mindset that is defined by values, guided by principles, and manifested through emergent practices. What many see most plainly through this methodology is how software products are delivered iteratively through sprints, or short, time-boxed periods or cyclical iterations during which a set amount of work is to be completed, but more deeply it represents a way of thinking that embraces change, regular feedback, and delivers on value. It uses full team collaboration, learning through discovery and continuous improvement. 

The names of the phases correspond to their focus and from the responsibilities shown here focusing on deliverables you can get a good idea of what happens within each phase. (See Figure 1)

The initiate and close phases occur once in each project, while the planning, development and deploy phases are cyclical and start with developing and deploying a minimally viable product and cycling through sprints to deployment of a fully developed product. The following is a brief description of the major responsibilities of the project team to the RIM team in each phase the of agile development methodology, remembering that planning, development, and deploy(ment) phases repeat in a cyclical manner over the span of a given project.

Initiate

In the initiate phase the project team works to ensure the RIM team is up to date and informed on the project’s contact or statement of work, vendor evaluations and scoring tool(s) as well as the product roadmap and backlog, a prioritized list of (new) features to be implemented as part of the project. The product roadmap is a plan of action for how the product (system or solution) along the path of the projects lifecycle. The roadmap provides context for the project team’s daily work but should also enable the ability to respond to shifts in priorities and resources.

Planning

During each planning phase the project team works to ensure the RIM team is up to date and informed on the non-functional requirements, sprint backlog (a prioritized list of deliverables or features to be implemented in the project, system, or product), requirements approach, application architecture, logical data model, data profiling and mapping as well as the service-oriented architecture (SOA) service requirements. “SOA defines a way to make software components reusable and interoperable via service interfaces. Services use common interface standards and an architectural pattern so they can be rapidly incorporated into new applications.” An example of an SOA might be to integrate systems so they may “talk” to one another to increase efficiencies.

Development

During each development phase the project team ensures the RIM team is up to date and informed on the design package, SOA design specifications, test plans, cases, and checklists as well as implementation planning and operational readiness. The RIM team should also be consulted on their input on end of sprint lessons learned or retrospectives.

Deploy

During each deploy phase the project team must ensure the RIM team is kept up to date on the production implementation plans. 

Close

As the project comes to the close phase, the project manager, and others responsible for collecting feedback must ensure that the RIM team is consulted on their input on end of project’s lessons learned and/or retrospectives. 

Unfortunately, this brief description does not do the process justice and I highly encourage you to investigate this methodology more deeply. The Agile Manifesto is a good place to start. I hope this quick explanation encourages further investigation.

Conclusion – Or a Simple Commentary on SDLC

There are simple ways to approach many processes such as the SDLC. Although modern information management systems contain complex hardware and software components, if you break down the development process as well as the associated the communications and relationship parts, you will see their down-to-earth traits before you:

1. SDLC should not be equated with rocket science. I’ve learned a bit about that topic courtesy of my late father who spent decades as a NASA engineer
2. One size does not fit all. This goes for organizations and systems
3. Systems development is not exclusively about IT. It’s also about RIM, your organization’s business, the customer – you name it
4. Use standards and other resources such as bodies of knowledge, indexes, best practices, technical reports, and principles, as appropriate. Don’t reinvent the wheel
5. Frequent communications may be required during certain phases of any given project and even into ongoing operations. Retention requirements can change so it is important to keep this in mind as systems are developed
6. Get to know the components involved across the organization. You will almost certainly do repeat business and see many of same people and roles on an ongoing basis
7. Customized documentation for your organization’s process can be helpful and an asset to your RIM team (when documentation is well managed)
8. Project tracking is required, especially in large or complex organizations. Your RIM team members may be working on a good number of efforts at any time, and it will make reporting to your chain of management easier if you have the information close at hand
9. Role-based training, where training is tailored to the responsibilities of the trainee, helps greatly. If your development team, and business partners understand your process and requirements, they are much more likely to be receptive to your presence in the process, and if you can get the attention of those at the proper level you may be able to better leverage your position in the process

The End is Where we Began

If you retain nothing else from this article, let us end with the sentiment I began with…Your RIM team is a critical partner and must be involved in the SDLC process from the earliest stages to ensure that systems properly manage information assets across the information lifecycle.

About the Author

Tod Chernikoff is a Certified Records Manager, an Information Governance Professional and a Certified Information Professional. He has over twenty-five years of experience providing records and information management and information governance services to organizations and clients. He has served ARMA International in positions at the local, regional, and international levels including as a member of the ARMA International Board of Directors. He received the ICRM’s 2014 Alan Andolsen Award in recognition of outstanding CRM Mentorship. He is a member of the Records and Information Management Team at Navy Federal Credit Union where he is helping to enable RIM operations across the global enterprise. The opinions and views expressed in this article reflect only those of the author.