Ready, Set, Whoa!
Plan Before Implementing RM Technologies

Congratulations! Your organization has made the commitment to move forward with an electronic records and information management (RIM) system. Through careful planning and research, you’ve found and selected the “right” solution and are ready to deploy. Now what?

Brent Gatewood, CRM

Bookmark and Share

Though the urge is strong to jump right in and begin the records and information management (RIM) software installation process as soon as it’s purchased, a cautious and methodical approach is advised. Getting to the point of approval and moving forward is often a long and arduous task, and once approved, it is tempting to jump into the implementation. It is advisable to pause and review the entire process before starting.

It is vital that the records management (RM) team be part of this process from the beginning. If initial RM team involvement wasn’t possible to this point, a process should be in place for its engagement at the earliest possibility. To proceed smoothly, your organization will need to have several teams in place.

Role of Teams

Assuming there was a team in place to define the needs and parameters throughout the acquisition process, it will need to remain involved throughout the deployment of the solution. This is important, as its members will provide continuity throughout the entire process. At a minimum, there is a need for two teams – an executive project team, which ideally will be the one involved from the beginning of the process, and an implementation team. The makeup of these teams is very important, as their members will be directly focusing the implementation and, ultimately, the look and feel of the end solution.

A RIM technology solution will affect many facets of the organization, so key groups will need to be part of the executive team, which will act as a resource for the implementation team as questions or needs that require executive comment or approval arise. Obviously, the ultimate makeup will be different for each organization, but the team should be as small as possible while respecting the organization’s cultural needs. Representatives from information services/technology, legal, records management, and human resources, as well as from key operational groups, are traditional candidates for the executive team.

The implementation team will be more focused on the technology and its implementation, including proof of concept (POC), pilot, and ultimate rollout. As this team will be heavily involved in the implementation, it is vital that it be made up of knowledgeable workers and management with broad exposure to the organization. These individuals must also have a deep understanding of the organization’s culture regarding tools and expectations.

Again, it is advisable to keep this team as small as possible to allow it to be nimble in responding to the project’s challenges and demands. Information services/technology, records management, project management, corporate education/training, and pilot department representatives are all candidates for this team.

Setting Goals and Identifying Scope

With your teams in place and the software solution selected, it must be time to move forward, right? Wrong! Now is the time to step back and finetune the goals of your implementation. (The general goals should have been in place as you investigated available vendors and their solutions). Part of negotiating with your vendor is identifying required services. Although it is tempting to rush through this part of the process in order to get the software purchased and installed before the opportunity to do so is lost, this is just as important as selecting your vendor. Follow these steps to fine tune the project:

Set specific goals. What are you trying to accomplish with this implementation? Set goals for both the short term and the long term. Make sure the team has identified goals for the POC (if applicable), as well as the pilot and the ultimate deployment. It is advisable to have staged goals to show measurable progress throughout the engagement. The goals should be functionally and technically focused. It is important to focus on the user experience throughout all phases of the project, as user acceptance will guide development and adoption.

Identify the scope. Define the scope in context of the project’s goals. The overall scope of the POC and pilot should be significant enough to be relevant to the entire organization. If the scope is too limited, it may be difficult to get departmental acceptance to proceed. If the scope is too large, the implementation could become too complicated and may fail. The goal in setting the scope should be based on relevance to the organization while showing the capabilities and benefits of the selected solution. Often the vendor and/or an existing user or user group can be a significant help in identifying a realistic and appropriate scope.

Finalize the statement of work. Once the goals and scope of the project have been identified, the team needs to work with the chosen vendor to develop the statement of work (SOW). This is a critical document and must be agreed upon prior to signing the final contract for the software and services. The SOW will guide all parties through the initial implementation of the solution and should identify resources and timelines, as well as milestones.

The importance of the SOW cannot be minimized. Ambiguities in a project often point to the SOW with all parties taking a liberal interpretation where convenient. The best for all parties is to have a carefully drafted and specific SOW that all parties can work against. If possible, tie an initial project plan and milestones to the SOW.

Align your resources. Even the simplest of implementations requires significant organizational resources. The larger the organization, the more detailed the resource requirements are for internal scheduling and compliance. Aligning these resources often involves managing internal and external team availability and lead times. When thinking of resources, project teams typically focus on those resources external to the organization. Focusing on external resources seems obvious because this is where the money is being spent. Often there are several external parties/resources involved in the project, including the vendor of the solution, hardware vendors, and possibly third-party implementation teams. It is correct to focus energies here – but the implementation team must also look inward.

Often resource issues are not with external parties, they are internal. Internal resources are typically allocated specifically to projects that are scheduled well in advance. As you build your executive and implementation teams, it is important to obtain commitment to the project because these team members will need to allocate resources to make the project a success. Have these internal resources review the SOW and project plan as soon as possible in order to identify any timing or resource issues. Also, there are often internal processes that are not accounted for in the project plan, including related items such as IS/IT (hardware acquisition or system testing requirements), human resources, or education and training. Identify these items early and incorporate them into the plan.

Why Now and Why These Tools?

Before you go any further, it is important to let your organization (at least the pilot groups) know what is coming. Education as to “why” is very important at this phase. The “why” needs to be clearly defined and documented. Work closely with your education and training department or team to develop a message that addresses the needs of the organization. Remember, people typically don’t like change – especially if the change will affect how they do their daily work.

Addressing international issues. Often, U.S.-focused companies view RIM software implementations from a risk perspective, while much of the rest of the world does not view risk associated to records in the same manner. The United States is easily the most litigious country in the world. Other countries may not have the same concerns around risk; therefore, the message must be tailored to their needs. Many countries have stringent privacy laws or other personal protections. All RIM software solutions offer significant benefits to the user and productivity; review the particular needs of those involved in the implementation and tailor the benefits message to them. Gaining support at the pilot phase is critical for success and user adoption.

Now Can We Start?

You are almost there. Prior to the official kick off of the implementation, all parties (internal teams and external resources) must agree to the initial project plan. An implementation like this is likely to be very complex with many dependencies. Often, the implementation will have multiple critical paths and significant resource demands – know these at the beginning of the project. Be prepared for these to change during the implementation.

While building your project plan and assembling your team, it is important to check for other projects that may be competing for similar resources (time, money, and people). It is not realistic to think that there will be no other projects active during your implementation. Understanding the competing projects and their relative importance to the organization will help your team to staff appropriately and manage expectations. Understanding other influences in the organization may help you build your executive team. As mentioned earlier, having key executive support is critical.

Once you have an understanding of any possible competing projects, it is necessary to fully understand the IT/IS processes as they relate to new technology in your organization. Most organizations have detailed processes and requirements for bringing new technologies on board. The project team needs to understand these processes fully and build these dependencies into the project plan. There will be dependencies related to the specification and acquisition of hardware, the testing surrounding hardware and system software, the reviewing of new software and data storage by IT/IS security, and so on.

All of these system reviews take time and resources, both internally and externally. It is critical to have an understanding of these processes while developing the project plan. Keep in mind that these requirements will likely exist at all stages of the implementation (POC, pilot, and general release), as well as the various environments (test/sandbox, development, and production environments).

Is This an International Deployment?

If you are part of a multinational organization, odds are that your software deployment will eventually extend to other countries. Many organizations pilot a solution in the “home” country first, prior to international release. Often, however, functional requirements and reporting responsibilities make a geographically limited deployment nearly impossible. As the use of information becomes more widespread, so does the sharing of information; because of this, it is more and more difficult to limit a deployment to a single country. This raises other issues.

Is your organization ready for a multinational implementation? This seems like a simple question, but the answer is significant. Your RIM solution will be enforcing the rules your organization has in place as it relates to record information. To determine your readiness answer the following:

  • Does your organization have rules documented and in place for all of the countries where it does business?
  • Is your records retention schedule comprehensive and does it cover all the information in all of the countries
    where you do business?
  • Are the privacy laws known and documented throughout your organization? Often, personal privacy laws can seem to contradict one another or some of your organization’s other policies.
  • Is the legal team aware of these issues and are there policies in place to address them?

Potentially even bigger than the legal and policy differences are cultural issues. There are likely several technical solutions that can meet your organization’s needs. There are fewer solutions that will actually work within your organization because of how you do business or the culture of your organization.

This issue is compounded when your organization is a multinational. There are different drivers for individuals and businesses across the world; therefore, to treat them all the same is short-sighted and could potentially derail your implementation. As mentioned earlier, the United States is risk averse, and this guides many implementations. This is not an issue in many countries; there are other concerns that will drive the implementation and acceptance.

Take the time to build teams from all aspects (and locations) of your organization, being conscious of local needs (e.g., customs and holidays). Work with these teams to discover their concerns and goals. It will take longer, but when you incorporate these needs into the larger solution, you will have a much higher acceptance rate.

Ready, Set, Go!

Now is the time to start. You have your team in place, you have a project plan guiding the team, and you have the best solution for your organization. Communication is the one thing that will keep your team focused and on task. Having a meeting for the sake of having a meeting is wrong. Having a meeting to keep everyone’s focus is vital. Decide what your interval should be, but pick it (e.g., daily, weekly, or monthly) and stick to it.

The team should meet to discuss goals and activities relevant to the plan and current status. Document the meetings and next steps. Don’t let the meetings last any longer than needed, but make sure everyone is informed and moving forward. Upper management briefings are critical as well. Keep all parties informed of the progress and needs. If everyone is informed, there shouldn’t be many surprises.

But, there will be surprises! Contingency planning will come into play. A RIM system implementation involves too many people and too much technology to go forward without an issue. Something will go wrong and something will happen to the schedule. If all parties are open, honest, and informed, the issues can be managed and resolved with little or no impact on the overall project timeline or deliverable. The key is keeping all parties informed and working together.

The Final Point – Documentation

A RIM system implementation is complex and very detailed. Your IS/IT group will demand a certain level of documentation. Every step and component of the project should be documented. All of the status meetings and decisions should be documented. All configuration and testing should be documented.

While the system is being designed and implemented, it often seems redundant to document many of the tasks that appear obvious in their design. Once the project is complete, however, this will not be the case. Being able to confirm actions taken in the implementation by review of project documentation will be a tremendous asset in moving forward in future phases of the project or in detailing what was done and why.

Now you are ready to enjoy your new software.

Brent Gatewood can be contacted at bagatewood@pelligroup.com.

From March - April 2010