In an Industry that seems to pride itself on "reinventing" itself every 12-14 months, change is a given in the day-to-day life of the IT professional. Unfortunately change, especially change at that high of a rate, cannot be absorbed by most end-users; and if the end-user community doesn't adjust have we really gotten our money's worth?
For a technology investment to actually make a difference in an organization, it needs to be used. For it to be used, it needs to be of actual service to the business processes and users of the organization. Too many times in my career have I seen organizations continually try to adapt the business process to the technical solution rather than the other way around. The "if you build it they will come" mentality just doesn't work. This continual change of tools and process leaves the user community confused as to how to respond.
The solution is to simply borrow a simple, but powerful idea from J.B. Glossinger's Morning Coach: 1% improvement each and every day.
Don't get caught up in what comprises 1% vs. 2% or 5% change in your environment. The underlying message is simply to keep the "perceivable" rate of change to a slow and steady pace that doesn't upset the end-user psyche. These approaches also usually have the side benefit of lowering the overall productivity hit to the organization during any project execution. This is because the amount of time spent with the individual user addressing the changes drops dramatically.
In almost every project I have ever been a part of there are ways to "hide" the degree of change that is really occurring in the environment. These almost always involve some type of "side-by-side" strategy and stay away from the "rip and replace" approaches. Below are some samples of project types and things that can be done to address the perceived rate of change. This is hardly exhaustive, but
Project Type | Strategies to lower perceived change rate |
Server Replacement |
|
New Application Rollout |
|
Application Upgrade |
|
Here are some key technology recommendations to include in your environment that can make this process easier in future projects:
- Use Distributed File System (DFS) for your primary network shares – This obscures the real path to file shares from the user community, so that share migration can happen without fear of creating "abandoned links" on the network
- Don't use actual server names for user facing Web or Network Services – Use CNAME or Application-specific A records in your internal DNS, so that you can easily change the actual server(s) doing the work without having to inconvenience the user by making them update links, favorites, etc.
- Where possible, use the same names/URLs for applications that are available both internally and externally – Eases confusion as users then don't need to remember 2 different ways of getting to the same app, even if you need to setup 2 different systems to handle the internal and external requests.
- Make a single landing page for all of your external portals – Rather than trying to teach the user community the URLs of all of your different systems (Outlook Web Access, Communicator Web Access, Citrix, SharePoint, Spam Filter Controls, SSL VPN, FTP Site, etc.) create a single web page that has links to all of your various systems. If it is easier for your organization, simply make this page a portion of your Intranet; just make sure that it is easy to find.
No comments:
Post a Comment