Chances are, you can get your document management system effective in less than a week. Of course, I'm making a number of assumptions about your organization, but if it functions like most, there should be only a small set of basic requirements that drive your document management compliance needs.
Document management for compliance is a basic function, yet I consistently see organizations
The basic root need of document management
If you're starting out (or starting over), you don't need to evaluate vendors and their software solutions and fancy imaging hardware, or high-priced consulting firms that are trying to sell you on the fancy hardware and software, as well as their services. What you need to do is keep it simple, and leverage what you already have in place.
Document management may have a myriad of applications throughout your organization, but I'm assuming for the context of this article that requirements are coming from some sort of compliance group. As I said, members of the department will come to you with what they want. At this point, you'll need to start asking a series of why questions until you get to the root of the need.
After you peel the onion, most likely the root need will be centered on audit survival. Your compliance department is responsible for ensuring compliance with a set of standards or regulations, and proper document management provides it with the necessary system of evidence that's required to survive compliance audits, either internal or external.
Your first job is to get members of the department to this point, so they can realize what the true issue is. It's not about fancy technology at this point, it's about solving a basic requirement -- audit survivability. The key with compliance is to have something effective in place as soon as possible. The longer you take with your solution -- any solution -- the longer your company stays exposed, and this is the biggest issue.
So, once we've agreed that it's an audit survivability issue, here's my five-day plan to get something functional and effective.
Nothing gets done quickly without executive sponsorship. If you're the executive sponsor and you have sufficient weight within the company, great! That's one less thing to do. If not, you must find someone with enough authority to exert influence over a cross-functional team. Then, assemble your task force. All people on your task force must have priority availability for the entire rest of the week. At a minimum, you will need a strong project manager, a business user (i.e., someone in the compliance department who understands thoroughly what needs to be done), a developer and a support engineer (the person supporting the application once it's deployed).
Day two: Assemble the team.
This should be about a three-hour meeting. The executive sponsor will set the tone for the project. It must be the No. 1 priority for all task members involved, and they should dedicate 75% to 100% of their time to getting this done. As a team-building exercise, create a project charter that spells out what the business case is, and specifically what you're trying to accomplish. The project charter should also formally acknowledge the project manager as the driver, who has the full cooperation of the executive sponsor for moving this project through the organization.
The rest of the day should be spent building the rest of the project plans (communication plan, scoping document, timelines, etc.), and communicating to external functions (e.g., architecture team, release team) that there's an important project coming their way that needs top priority.
Day three: Get crystal clear on requirements.
The core project team now needs to get crystal clear on the requirement. This is formalized in some form of requirements document, like a product requirements document or a business requirements document. Keep the requirement as simple as possible. There are really only four things that need to be figured out: imaging, storing, searching and retrieving.
Remember we want simple, not simplistic. Simplistic means you've overshot the simplicity theme, and found yourself in inefficiency land.
Don't try to solve anything at this point, just document the basic requirement. The project manager should be strong enough to sense scope creep, and push back. You have only a few days to get this done.
Day four: Build the simplest solution that will work.
If you've kept the requirement as simple as possible, then the design should be easy to keep simple as well. Your developers have only a day, so there's no time to experiment with fancy architectures or cutting-edge technology. Let's just get a basic solution in place -- as long as it works. Remember, we want simple, not simplistic. Simplistic means you've overshot the simplicity theme, and found yourself in inefficiency land.
Flexible metadata management is a bonus (i.e., the ability to customize and categorize the keywords), but it's not necessary at this point. If it's easier to just give them a block of text, just do that for now.
Day five: Deploy and celebrate.
Depending on your release management function, you might not be able to put the solution into production right away, but I would still claim victory at this point. Now it's just a matter of process.
If document management is on your menu, there's no reason why you can't go short order on this one. By recognizing the true need of the organization, and following my plan, you can have effective document management by the end of next week. Start today by identifying the executive sponsor who will clear the path for your solution.
John Weathington is president and CEO of Excellent Management Systems Inc., a San Francisco-based management consultancy that helps companies dramatically improve efficiency and avoid penalties and fines. For more information, visit www.excellentmanagementsystems.com.
This was first published in November 2009