As an online marketer, I used to work in different environments, but since joining Foliovision, I spend virtually all my time on our clients’ content management systems. Some days ago, I logged into a completely different CMS after a long time. It didn’t look bad at first glance, but spending just a few minutes working with this interface was enough to see the striking difference between this CMS and our own; this one was really medieval! I am a marketer, certainly not a hard-boiled developer, and for the first time, I’ve summarized my thoughts about what makes a good CMS. These are the pillars of success but also the risks involved.

I. Low initial costs

This means open source, choosing from the three respective candidates (here we explain why we chose Wordpress out of these three). There is a crowdsource counting dozens of millions of people who develop, test, rate, and upgrade several open source CMSs. You can’t beat this crowd with your team. Spending weeks developing your own or buying some obscure CMS from another company means you’ve wasted money form the beginning.

RISK: Some open source projects serve for years with the same or even increasing quality. Unfortunately, some start to slide backward as the time passes, and you have to leave the sinking ship at the right moment.

II. For all clients and purposes

Of course, you have to add “within the range of what CMS should provide.” There is nothing worse than getting your first BIG client and then realizing that the wooden legs of your CMS can’t accomodate your vision. Our example: we need to serve both a local Toronto realtor and a major Canadian insurance broker with different traffic, database requirements, and marketing strategies — not an easy task if you’re not prepared for it.

Analysis and Recommendations for Information Technology User Support Provided to a Government Field Office

Chapter 4

Documentation for the User

Documentation as User Support

As mentioned earlier in this professional report, one of the key services of IT user support in the Organization is to provide documentation. The IT staff in the field office is required to provide user documentation for both installed applications and applications that are either locally developed or modified. The IT program is also responsible for providing and developing system operating manuals and application software user manuals. While the functions of user support through documentation have been specified by the Organization, the format and means for providing the documentation to the user have not been specified.

Because of the absence of standardized practices for managing the documentation in the field offices, most field office users have access to literally hundreds of documents in inconsistent formats utilizing many different methods for retrieving the documents. For example, users may have to go to the office intranet to retrieve the latest office computer usage policy. The user may then need to dust off a binder to retrieve a "hardcopy" of an e-mail containing instructions on how to reboot a system. Files that have been digitized are in various file formats such as ASCII text, WordPerfect, Microsoft Word Document, and Rich Text Format. A user manual for one application may be found by the user in a hardcopy "software binder", but a user manual for another application may only be available on a computer screen through the program's "Help" menu.

Analysis and Recommendations for Information Technology User Support Provided to a Government Field Office

Chapter 3

Information Technology Changes for the User

Introduction to Change Management Systems

Ideally, formal procedures should be in place for IT users to be able to request IT hardware and software changes, for users to be notified whether the requested changes are approved, and for users to confirm that the tasks performed to address the requested changes are completed. Actually, informal procedures are often followed by users to initiate changes in IT. A review of available literature shows that informal procedures to manage change could pose an obstacle for the efficient use of resources and for ensuring that projects meet organizational goals (Damodaran, 1996). Without formal procedures, it is unlikely that adequate communication between the user and IT staff would be possible, hindering the benefit of the participatory design process.

Analysis and Recommendations for Information Technology User Support Provided to a Government Field Office

Chapter 2

Previous Analysis of Field Office User Support

During the five years that the author has been in charge of the IT program for a government field office, a number of formal and informal user surveys have been conducted by various IT groups within the Organization. The intention of the surveys was to identify how IT could provide improved support to the users. In most cases the results from the surveys identified no significant problems in the area of user support or, more disturbingly, the surveys were left unanswered and the results were inconclusive. Current organizational performance measures used by the organization for user support also did not give a true measure of the quality of support being provided to the user. Informal interviews with IT professionals conducted in the past few years by the author have revealed that IT managers have difficulty in identifying the improvements needed for their own user support programs.