As we welcome a new year, you may be thinking about new funding and new projects. It may be time to tackle that growing storeroom of paper files or that growing debate about getting rid of the shared drive, or you may want to do a serious test of cloud-based collaboration systems. Whatever the project, a request for proposal (RFP) will help you to not only define the problem but also find the right solution.
It is hard work—some of it tedious, some interesting—but in this case, it is not about the journey; it is about the destination. I can’t tell you how good it feels to select the right vendor, start digging into the project and know that you (the team) made the right choice.
A RFP is a document that states the requirements for the system you have envisioned, as well as the project requirements and helps the vendor understand the fundamental problem you are trying to solve. A “proposal” is a vendor’s interpretation of your requirements and how their product fits those requirements.
A RFP forces you to actually define not only your “problem” but to understand the underlying technology that will solve your problem.
The best part of doing a RFP is that it forces you to do your homework and to actually define not only your “problem” but to understand the underlying technology that will solve your problem. You will have to really dig in and document your current environment (the "as is"), which may involve counting paper, documenting paper sizes and conditions and researching shared files to see what kind of files are there and how often they are used. It can really become fascinating to find what people do and don’t do with their work output. Not only that, if you work with the potential users of the system, you will begin to understand how they work and interact with others in your company.
For example, I typically develop a questionnaire to gather information about the documents, how they are used and shared, how they are named, etc. One question for a recent effort was, “Do you share and collaborate with electronic documents inside of your department?” The respondent’s answer was, “Sort of.” This type of answer was consistent with other answers he gave, and I realized that this person was really disconnected from the rest of the company. As it turned out, this was not unusual, as I found there were others that also worked in isolation.
We, the company and I, had no idea how disconnected many of the workers were and that they also operated in a very insulated fashion. Their file names and file organization were completely subjective, and they often could not explain how they would find a file in their file share. This was, as I said, a revelation to the management of the company and actually showed management’s own shortcomings with regard to effective management and productivity. (“Geez, how did we not know this was happening?” was one comment.)
Based on the questions and responses, we also knew that we had a secondary problem—poor management. While a document management system would not solve this problem, I explained that poor management would cause the project to fail.
This also led us to look deeper into how people worked and collaborated within the company. We found that because of the “isolation” of some individuals, they were working with stale data and, subsequently, putting out information that was not current. We traced several stale documents that got into the training and marketing information and had been published. Not good!
As a result of this new information, we backed up and realized that we were not ready to do an RFP yet and needed to resolve some in-house work procedures and issues first. Also, we used this opportunity to assume that this problem was actually larger than originally characterized and expanded our horizon to cover additional people in a larger sampling of users.
Once all that was settled, we started back on developing the RFP requirements by interviewing key small and medium-sized enterprises and programmatically looking at their shared drives. One interesting, unexpected result was that we also uncovered several users who became champions for the project, because they wanted to do more with the technology than we originally intended. During implementation, we worked with these champions to get their departments on board first, and then, they became our in-house success stories for the system and technology. It was a win-win for everyone.
All told, this was time well-spent for both the company and the vendor that was finally chosen. Our RFP had much more clarity to it, there was greater buy-in from the users, management got a wake-up call and got behind the project and we hit the ground running. By the way, those disenfranchised workers were given additional support and became our biggest advocates.
Happy New Year!
Bud Porter-Roth has over 20 years of experience as an ECM consultant, with a focus on cloud collaboration, electronic document management, records management and paper document projects. Follow him on Twitter @BudPR or contact him at info@erms.com.
