Part 2 of our series, on setting expectations for Cloud Document Management.
Over the past 5 years, nearly every Community IT infrastructure project has included some cloud document management component. As we have helped clients plan and migrate their platform for managing documents to the cloud, several trends have started to emerge.
In this series of posts we’re covering different aspects of a migration project and how to be successful. As you think more seriously about migrating to a cloud based document management solution please consider our tested and proven methodology:
- Outline your requirements to build your business case
- Define your project scope using research and due diligence – tips in this post
- Set expectations and educate users and management early with regards to what the system can and can’t do, and the extended time and investment of time required – tips in this post
- Focus on usability, usability, and usability
- Engage senior management as champions
- Expect your implementation to take time, and plan accordingly. This is a major investment you are undertaking, and needs planning and attention to succeed.
- Checklist of questions to ask your IT provider before migration
Define Your Project Scope Using Research and Due Diligence
After you have defined your business case you will also need to define the appropriate project scope: requirements, schedule, cost, system design, success criteria and deliverables. These are the foundations for a successful cloud deployment project.
Begin with research. Network with colleagues to learn about their systems, and any pros and cons they can pass along. In other words, the sales rep interested in selling you a product should never be your only source of information on what that cloud solution does and how it works in real life.
Here are a few examples of due diligence around pros and cons of a cloud based document management solution:
- Your current file sharing solution requires you to download email attachments to your local computer hard drive before you can save it to the on-premise file library. Your future cloud collaboration platform will allow you to save email attachments directly from your email client and reduces the time it takes to save each attachment by a few minutes. Highlight this efficiency gain!
- Conversely, if it will take two steps to store email attachments with the new system instead of the one step you currently use, make sure that no one will be surprised at roll out to find out it will take a minute or two longer (but highlight that with the new system email attachments will be searchable/shared, etc).
- Your current file sharing solution has a 5GB per user storage quota for user but your future cloud file sharing solution has a 100GB per user storage quota. Highlight the increased data store limit, perhaps with examples of the number or types of files you will be able to store, or current usage as a benchmark (most users don’t really know jargon about storage capacity).
Set Realistic Expectations
When proposing changes to your organization, it is essential to set realistic expectations as early in the process as possible. Although you can start by highlighting the biggest benefits and efficiencies of the new systems, you will also need to be honest about the potential limitations. You may reduce functionality in different operating systems, your new system may have additional software and hardware that will need to be purchased, or you may have incompatibility with existing systems that will no longer integrate. The user interface will most likely change, and in some cases will change dramatically.
A good consultant or sales rep should be able to tell you the cons as well as the pros about moving to cloud based document storage. Community IT Innovators has started to regard our introduction to SharePoint as an “un-selling” process – we consciously point out the negatives, which can help us gauge an organization’s tolerance for change. If the benefits are seen to outweigh the drawbacks, then we know we have good organizational buy-in for the project.
In the decision making process you will need to examine carefully any processes that need to be changed, or created, for effective use of the new platform. If there are any hidden or future costs associated with the system, they need to be brought to light.
Here are some examples of process change or hidden cost considerations:
- Your organization stores large video files in your on-premise file server but your future cloud file sharing solution does not support files that are larger than 1GB. You will need to inform your design team that they will need to continue to use a local server or find a new solution such as a Digital Asset Management solution.
- The data file for your organization’s accounting database is stored on the accounting share of the on-premise file server. If you are migrating to a cloud document management platform and the on-premise file server will be decommissioned, you will have to find a new solution for storing the accounting data. This additional cost needs to be included in the total project cost.
- Your organization doesn’t have a password expiration policy on your on-premise email system but your future cloud email solution requires passwords to be changed every 90 days. You need to confirm that all staff understand they will now change their passwords every 90 days.
- Your current file sharing system uses the desktop user interface for managing files but your future cloud solution is a browser-based system. You will need to convince your colleagues that the browser can be an effective file management tool.
You should expect to be able to test the proposed systems with specific examples of your business case (which your proposed system should improve, not just change!) For example, you should expect the sales rep or consultant to be able to show you either a demonstration with a sample file from your organization, or a very similar user case. Ideally different systems can be tested on the same file set, by your staff who will be users, to determine which of them best meets the defined business case.
Some examples of testing different options:
- Most cloud based solutions have a trial subscription period during which you can test use cases and review the user interface for free. Testers at your organization should set aside time to delve into the new interface and try to use it, not just browse through it.
- The testing should involve different types of users: power users, average users and neophytes.
- You also need relevant stakeholders involved in the testing phase: department heads, staff, executives, external partners etc. For example, if the business need is successful collaboration with field offices, you will need to include field office staff in the testing phase of the project.
- If you are in a mixed operating system environment you will need to test the new cloud platform on different operating systems that are in use.
Finally, you will need to take into consideration the culture of your organization and plan for roll out, training, and usability testing and corrections after implementation. Your decision on a new cloud system shouldn’t be delayed by a fear of roll out, but a good sales rep or consultant will help you take roll out and training demands into consideration as you compare products.
Here are a few examples of issues with training users and recruiting champions:
- How difficult is the retraining going to be for your organization? Do you have enthusiastic technology adapters or is your organization culture more cautious?
- Do you have executive cheerleaders who can shepherd the roll out along? How long will you have executive support, and how enthusiastic will your leaders be?
- How long have similar organizations taken to roll out the proposed system?
- Does the system appeal to more technology minded adopters, so your technophobes will be hopelessly confused by the training? Is your proposed system and training heavily focused on non-technical users, which will leave your more tech-savvy staff bored and underwhelmed?
- What is your plan for usability testing over the first year, and are modifications possible after your roll out? What are the prospective charges for modifications after roll out? Is the system geared to be “set it and forget it” or does it evolve with use? Could it evolve out of control once users start creating their own files and sub systems? How will you update and maintain your new system over time?
Part 3 in this series will cover usability, usability, and usability. If you missed the previous posts you’ll find links at the top.
If you’ve missed any of our past webinars or posts on cloud document storage platforms or planning, you can find more resources here.
You can download a pdf (1.2MB) or share this entire series online here.