Implementing Records Management: The Morning After

By Ganesh Vednere at 2008-09-18 14:35:00 |

So you've chosen the right records management (RM) package, got the smartest developers in your firm to design and develop the solution, and today you successfully went into production with the application. Lo and behold, it works! High five's all around! You start procuring copious amounts of champagne for the celebratory party.

Problem is, you'll wake up tomorrow with a headache that's not just from the bubbly. Some users will chafe at having to change cherished ways of working. You'll have to deal with an inevitable surge of support and enhancement requests. Your IT department may begin a series of risky configuration changes. And then you'll discover rafts of new and different content types to deal with.

So, your party was premature. It is only after the RM application is implemented and users start to employ the system that will you be able to assess the effectiveness of the policies, procedures, and technologies that you've put in place. Adoption and compliance must be won, over time. Let's look at how to do just that.

Plan, Adapt, Steer

Any records management system can cause turbulence within the business, as users typically get asked to alter long-standing processes. Rather than automating an existing task, your colleagues may now have to perform extra steps to ensure that records are properly categorized, attached with appropriate metadata, and stored in the right folders in the new records management repository ("what, no share drive?").

Some users may be reluctant to follow the process consistently and some may not follow the process at all. Participants may raise concerns with management about the additional burdens imposed by the new RM regime.

So how to deal with this issue? The records manager will have to make sure that an adequate level of communications has been established both within the user community and also at the management level. The business case -- you have a business case, right? -- needs to stay front and center here. At the same time, records managers need to be prepared to make adjustments to the program and the technology, based on the feedback from the user community.

For example, business users may want changes to the lay out of the folders or folder hierarchy or even record attributes, after the system goes live. This is normal: users will come to see that the planned folder structure does not really work in practice and needs to become more "user friendly."

From a technology perspective these may require relatively minor changes, but they do go a long way in getting "street credit" with business users. Records managers, however, need to be prepared to push back on requests that seem like scope creep, especially if it does not add tangible business value. This means prioritizing change requests based on their usefulness to the business and to the larger community of participants.

Consider a steering committee comprised of users, executives, and IT that supports the implementation process and approves enhancements against business objectives.

Prepare for an intense support cycle

This is one area where records managers need to pay special attention. Initial technology funding frequently just covers application development, so it comes as a surprise to budget committees and senior management when they receive the estimate required to support the application in production.

Perhaps senior management assumed that once the application got built, the enterprise as "done" with records management and could move on. It will fall to you to disabuse management of this fantasy.

Records managers really need to evaluate the support requirements for the records management application and ensure that adequate resources get applied from the start. Nothing is a bigger turn-off for users like lack of adequate support. The key here is to recognize that support is not just having a help desk for the records application (though that's essential), but having support around the record processes, procedures, storage, retention, and disposition of documents. All of these have to come together through a single support window.

Depending upon the type of the enterprise, record managers sometimes get caught off-guard with the volume of support calls and e-mails coming in, especially during the initial days, if not months. To resolve these issues adequately, you will need sufficient skilled resources.

At the same time, records managers need to control the scope of the program here. Recognize the difference between support requests (something not working or not understood) and enhancements. The latter you'll want to run through the steering committee you created above.

Tread Softly on Patches, Hot Fixes and Upgrades

Many records managers also get caught off-guard by the volume of patches, hot-fixes, and version upgrades (either on the part of the records management vendor or other dependent components and applications) that plague even the most well thought-out systems.

Many records managers would like to think that hot fixes and patches have absolutely nothing to do with them ("It's IT's responsibility!"). And yet system upgrades can wreak havoc with your core records management application.

I recently came across an example where IT decided to upgrade a major business application but no one bothered to check the integration with the records management service, with the result that records could no longer be migrated from the application into the records repository. Clearly this could have been avoided had all applications that produce records performed a documented validation test to ensure that product upgrades do no interfere with the records management system.

There is also the issue of upgrading the records management application itself. If the records management application is heavily customized, then vendor upgrades may potentially break part of the code. These need to be validated in a sandbox environment prior to patching into production. Of course, by keeping the design of the records management application simple and focusing resources on adoption, perhaps some of these issues can be contained.

Establish compliance plans

One of the most important facets of records management implementations is to develop a post-implementation compliance plan for the business users.

By compliance, I mean adherence to the policies and procedures as encapsulated in the system. The objective of the compliance plan is to establish baseline dates by which the businesses have to start using the records management system in entirety (i.e., when will all of the records, both legacy and go-forward, start to be in the records management system). The plan will detail all of the activities, milestones, roles and responsibilities to enable the business unit to fully convert over to using the records management processes and systems.

As with all software implementations you won't want to undertake a "big bang" approach, but rather take slow and iterative steps. Hence it becomes crucial for the records management team to establish a compliance plan that details how, what, and when businesses will start to comply with the records management policy and procedures.

The compliance plan will lay out in detail each of the steps that have to be completed in order to fulfill the records management requirements. The plan also allows the records manager to track and monitor how well a business unit is doing against the established goals and report back to the management on progress and any deficiencies that need to be corrected. This has an added effect of getting the business unit management to have their users conform as well.

The purpose here is not to spring "gotchas" on the business, but rather to figure out where and why things may be going wrong or going well.

Plan for new record formats

With the advent of "Web 2.0," all sorts of new document types have popped up. The record management community is abuzz with talk of mashups, wikis, blogs, and tweets, to name a few. Records managers are asking which of these content types constitutes a record. Needless to say it will not be long before you start seeing some of these as being responsive during litigation discovery -- at a time when most enterprises still struggle with managing e-mail records.

The key point here is that any records management system -- no matter how sophisticated and cutting edge -- will eventually need to stretch to accommodate additional record types and formats. Part of supporting a records management system is to understand that newer technologies and additional content types will always lie around the corner, and hence records managers need to periodically assess the state of their records management systems.

This evaluation will include available features and limits of the existing records management systems to support different types of records. Conducting this evaluation and analysis will assist in determining the gaps and provide valuable data in planning augmentations.

Conclusion

Good planning and management it can make an incredibly complex RM implementation much more straightforward. Of course you'll want to focus on compliance with records management policies and processes, but this will require appropriate support structures in place to enable usability, continuity, and adaptation.