\u2026 often aren\u2019t found in smaller IT shops!<\/p>\n
It\u2019s sad but true, smaller shops often don\u2019t follow the \u201crules\u201d for an IT rollout, at least not when compared to the big guys. The big guys with their big budgets will plan, test, lab, torture-test, and \u201cwhat-if\u201d an IT rollout to death before committing it to production. They will have a rollback plan in case things don\u2019t go as expected and they generally spend a lot of time prepping their user base for the coming changes. Smaller shops \u2026 well, not so much.<\/p>\n
Yes, I know the previous statement is a sweeping generalisation but there is more than a grain of truth to it. For whatever reason, smaller operations seem to rely on the \u201cswitch it on and go\u201d mode of rollout and then hope for the best. It may be because of constrained budgets or it may be because of lack of knowledge, either way it can be a recipe for trouble.<\/p>\n
So, to help smaller shops, here\u2019s a list of things that can go a long way towards ensuring your rollout does what you expect it to!<\/p>\n
1. UNDERSTAND<\/strong> your environment. List ALL of the bits and pieces that are part of the environment, most specifically the programs that you use in the environment. Ferret out everything that you can as it will help you ensure that nothing is missed AND it may help you find out about that one \u201ccritical\u201d program that one person uses that no one else seems to know about (they DO exist). <\/p>\n 2. TEST<\/strong> your programs \u2013 ALL of them \u2013 in the new environment. You can do this on a single upgraded machine or use a virtualisation product like VMware Workstation to provide an environment to test. The point is make sure your critical applications will work in the new environment. If you are upgrading things like Excel, make sure that the new version operates the way you expect, lots of things can change in the backend and \u201cbreak\u201d legacy applications. Also, keep in mind that physical hardware can have issues with new operating systems or new versions of various programs. You need to test things like printers and scanners with the new environment. Trust me when I say that your costs will get totally out of control if you have to start \u201cfixing\u201d things after the rollout, specially so if you find that big ticket items like multi-function printers will not work with the updated environment. <\/p>\n 3. PLAN<\/strong> your rollout in stages, if possible. There is absolutely nothing worse than doing a big-bang rollout (ie changing absolutely everything) then finding out nothing works. It is much easier to manage a rollout in small chunks as you can catch problems and fix them before they turn into nightmares. <\/p>\n 4. PREPARE<\/strong> for a rollback scenario. Always have a way to reverse or revert back to where you started if it all goes pear shaped. This means having good, tested backups and recovery processes in place as well as a detailed plan on how to get back to where you were. <\/p>\n So, it all comes down to planning and testing. Yes, there is a cost involved but, like any form of insurance, it\u2019s a cost worth its weight in gold if a \u201cpayout\u201d is required. The total cost for a system upgrade can be many times the capital cost of hardware and software if the rollout goes horribly wrong and the delta between what you originally planned for and what you ultimately pay will be many times greater than the cost of planning and testing. Even if most things work the costs can still skyrocket if key pieces fail or you are faced with having to bolt-on a bunch of minor fixes after the fact (creeping cost for a new program here and there, another hardware upgrade, a new printer, and so on and so forth). <\/p>\n","protected":false},"excerpt":{"rendered":"