I have been involved in a number of small organizations in which I held either explicit or de facto roles as a director of communications or webmaster. These include the Iron Dragons, the University of Toronto Engineering Society, the Leaders of Tomorrow Working Group (WG) for Engineering Science and later the Graduate WG, as well as project groups for several courses.
As a web development tinker, I have been able to introduce a number of tools to these groups, including:
- Drupal websites.
- Wikis, using MoinMoin, PmWiki or MediaWiki.
- Mailing lists, typically with an instance of GNU Mailman.
- Doodle for scheduling meetings.
- FTP accounts for file sharing.
- Google Apps e-mail, calendar and documents.
Some thought processes are useful when choosing and deploying such tools.
Identify the spanning set. I have written about this previously. Technology needs to be applied judiciously. For example, using MediaWiki for most small projects is a little bit like sandblasting a soup cracker. Ask yourself the following questions:
- How computer-literate are my users? How much time and effort can they devote to learning new tools? How much can I devote to teaching them?
- What communication is most important? Is it the communication between executives? Between regular members? From the executive to outsiders? Will the software I am considering obstruct the flow along these popular channels?
- What computing capability is available to me?
- How much time to I want to spend babysitting the configuration? Are my other responsibilities to the organization more important?
- Do I want to write code that someone must later maintain?
The answers should help guide your selection of software tools for the organization. Further, once you have committed to a tool, they may govern how you use its features. Larger Drupal websites rely on interlocking contributed modules, configuration and theming. Often there are many ways to skin a cat; instead of using the first you come across, research and make a careful choice.
Question the need for control. Not every organization is committed to being an Open Organization, but many would do better to try. Consider information:
- Regular reports - Reported activities and future plans allow monitoring and participation.
- Information accessible - Even internal operational information is available by default.
- Explicit confidentiality - It is explained what areas are confidential, why and who access them.
The first is often a requirement; especially in representative (student) government, where reporting of minutes is a mechanism for accountability. Even in smaller groups, #3 can be useful. By acknowledging and delineating what information is shared, you defend the organization against the unpredictable actions of members who feel they are being shut out of decisions they care strongly about. Finally, #2 can serve two purposes; the first is recruiting. The casual visitor may be enticed if (s)he sees something intriguing; it would take considerable effort to replicate this effect through deliberate marketing. In groups whose activities include leadership development, internal operational information further serves as evidence of the development process, as well as fodder for reflection.
In using software, implementing access control to hide certain information is always extra work. With the above principles in mind, question why it is necessary to maintain separate and perhaps dissonant sets of information for internal and external audiences.
Use Free Software. Call this bias if you like, but it is more reasonable to point your successors to http://openoffice.org than to expect them to have access to a (questionably legal) "copy" of Word. If your organization is a business, the former practice does away with worries about software piracy.
Free software is not without its faults, however, one of which is that it develops in an ecosystem. Projects which fail to attract users stagnate and ultimately disappear. Balance the features of available alternatives against the apparent health of their community; as with proprietary software, avoid "vendor lock-in". If the community behind your current software seems to be dying, migrate out.
Plan for the future. What is your level of knowledge in web development and software administration? Can you expect your successors to reliably be as knowledgeable? Even if not, favour simpler configurations which are more easily maintained. Perhaps this entails (where it means no inefficiency elsewhere) changing practice in your organization to suit the stock behaviour of some software.
Documentation is invaluable. Even if your own knowledge was assembled from hours of schizophrenic Googling, save and share a collection of links. Spend a few hours recalling problems which at first had you stymied, and explain how you overcame them. Keep this documentation in the simplest possible form, to remove any barrier to your successors in updating it.
It is the organization, and not you, which learns lessons. Do what is necessary to ensure the organization's future behaviour reflects them. The alternative is that your successor, knowing no better, will repeat your rookie mistakes, undo your hard work, and—worst of all—potentially damage the organization's data.
Work hard. If you find yourself grappling with these issues, you have already decided that your organization can communicate more effectively and therefore work better with the use of technology. But you need to do more than simply mentioning as many Web 2.0 social networking sites as you can in one breath ("FacebookMySpaceTwitterYouTubeDigg..."). Indeed, shoddy work can mean an unintuitive setup that will create an aversion reaction in your peers, at which point you have immunized the organization against all technology. The only course is to do the hard work necessary to get a good suite of tools which are accepted and adopted.
