Here's a helpful tip for anyone that needs to send automated emails for some reason. I've been using this method for a few years to automate emails I send out regularly for project work, e.g. status reports. Maybe this is useful to someone else as well?

This assumes you have some form of Unix, cron support and mailx installed. I think Mac OS X will give you all of these out of the box. I have the developer tools installed, so I'm not sure what the default configuration is any more.

Say for instance you regularly update your team by email with project status reports. You could create a cron job that says, "Mail me a project status report template every Friday that I can fill out, then send the reply to my team." No fancy software needed. You can do it all in email via a cron command. From your Unix prompt,

1) Input crontab -e and press enter

2) You're now in a text editor. Most likely it's vi. Enter the following:

0 0 * * 5 mailx -s "This is the subject" -r replyaddress@somedomain.com recipientaddress@somedomain.com < /path/to/somefile

3) Now you need to save. If your server's editor is vi, you'll need to type ":wq" to write and quit. Now you're done.

I'll deconstruct the crontab commands if you're unfamiliar:

0 0 * * 5 mailx = Tell mailx to send the message every Friday. Literally, this is saying, at :00 seconds on the 0 hour (midnight) on every month of the year on the 5th day (Friday). If you want to know more about the date/time intervals, check out this documentation

-s "This is the subject" = This is the option to include a subject in your email.

-r replyaddress@somedomain.com = This is the option to include a reply-to email address. When you hit reply in your email reader, to TO: address will now be whatever you've put here, e.g. the Team's email alias.

recipientaddress@somedomain.com = This is you obviously, but if you want this reminder to go out to everyone, this can be the team email alias.

< /path/to/somefile = This is the path to the message you want to send in the email. In my example, this would be the project status report template.

That's it. Easy, no? Email, in my opinion, isn't going away. I would guess that even though spam might make email a productivity drain, for most business users it's their number one productivity tool. I get the efficiency of using CMS rather than email. I don't need to be sold on that. But I need to use email with most of the groups I work with because there's no resistance to using email in those communities. With these groups, I'm not up to the task of introducing them to a new system.

But one strategy that could serve as a gateway to using CMS might be to couple scheduled email to the CMS. Perhaps you could CC the messages to a rich blogging system like Traction Software that accepts incoming email and the messages will be automatically posted to a web site. Traction would be cool because you can then email reply via Traction on the status report and the reply gets submitted back to the team via email and once again captured in the site. Anyway, this is just food for thought. I started out this post just wanting to capture my email scheduling process, but my posts on doing project work often seem to come back to how to integrate those processes with blogging.

I like the meeting format described in this Business Week article on Marissa Mayer, VP of Search Products & User Experience at Google.

New features are digitally projected onto the right side of a conference room wall, big as a movie screen. Everything Mayer and others say is transcribed and projected on the left. Underneath both looms a giant mega-timer. Everyone gets an average deadline of 10 minutes. Mayer and her team add and subtract to the feature as time runs down. It is iteration at lightning speed.

While the formal quick pitch format is unnecessary in small groups, what makes sense is that this format allows for new features to be proposed with frequency high up the chain of command in a large organization with some amount of structure in terms of time restraints. I assume engineers working on the project can pitch directly to Mayer. The critique format also allows a good deal of iteration while exploring ideas so they can be worked on some more and revisited. This excerpt describes the process:

What's most fascinating to me is the projection of the demo on the screen and the immediate capture of the discussion, which I assume goes directly into that internal project management system they talk about. That's excellent. Capturing these trasactions of verbal communications, although using brute force methods of manual transcription, is what knowledge management is about. The post-processing and information retrieval in their system is what glues it all together. That they're openly capturing everything in these meetings is what makes it effective KM work. It's not so hard to imagine all the pieces fit together into a product or at least a process that could be sold as an idea for realistic KM at work:

• WebEx type presentation software
• Transcription (manual now, voice recognition later in the retrieval system?)
• Search mechanism with some simple hooks for metadata (parsing for based on minimal formatting conventions, e.g. "[field name]:")

If enterprise meetings all went this way, mining of the types of tacit information usually floating around in conversations might begin to mean a bit more. Taken too far it could make a lot of information also mean less I suppose, but who cares as long as we have bigger hammers to tackle the signal to noise problem in retrieval. So I'm wondering if that type of process could be adopted as a model and be rolled into a solution. I want to see more under the hood at Google.

Baseline has a feature story exposing bits about How Google works and what we can learn from them. Most of the story focusses on the unique infrastructure Google has been building to support its expanding needs. But most interesting to me is the small bit that takes a lok Inside Google's Enterprise. The article refers to Page and Brin's pronouncement in their IPO that the company is not conventional and doesn't intend to become so. And this appears to be true judging by the way they run the company internally. They won't follow the pattern of what's been done to run businesses in the past if they can find a better way themselves.

This is exactly the attitude that has slowly been building up a revolution inside the ranks at enterprises large and small. Knowledge workers, fed up with the way things are have turned away from conventional software to manage they way the work in favor of better, simpler applications that get out of their way and let them get on with with it.

The article talks about how Google uses a simple system that manages project information using relatively unstructured email as the interface. The system mails employees every week asking what they worked on the week prior and what they plan to work on during the current week. The response is parsed, fed and indexed into a searchable system that is open to the enterprise so that anyone else can track other employees projects that they are interested in. They call it "living out loud".

What they're doing is creating an open system that matches an open knowledge sharing ecology. That openness allows for the "cross pollenation" of ideas. Even better, it provides opportunity for the one thing that is driving nearly every aspect of the innovative web today -- open conversation. They're creating a system that better ensures sustainability because it works with an existing, accepted process -- communicating through email. This removes barriers to use because email is easy. The unstructured nature of the format also means that it can evolve with the needs of the system on the back end. The computer works harder so that the knowledge worker can just dash off a note and get on with their work.

Wow, right? That's revolutionary thinking, and it's so simple on the user-facing end that you hardly have any excuse for not participating. And opportunists that exploit the system by mining and tracking with it will benefit from it immensely. This is the evolving face of knowledge management. The idea of telling the technology to get out of the way so we can do work is what's driving the enterprise blog and wiki revolution. We all need to publish, share and collaborate, but we want to do it as simply and effortlessly as possible. Google embodies that idea completely inside and out.

My article on using Wikis for project documentation has just been published on LLRX. I'm groaning now seeing some of the badly worded sentences in that article. I should never publish articles unless they pass through a copy editor or something. Anyway...

This article is intended for library staff who are looking for ways to capture internal process, procedure and project information. It describes the Wiki experiment I started in my organization over a year ago and the process of getting the Wiki organized, accepted and used by our staff.

I started the Wiki for my organization shortly after taking over the intranet site for our staff operations. The prior site consisted of manually maintained html pages. I intended to test the Wiki as an alternative for project-oriented documentation, but found that it made a good replacement for many of our modest documentation needs. I was simultaneously testing out some light content publishing systems as alternatives, but found that the Wiki was a better fit. This article attempts to offer our observations as users of the Wiki and provides some insight into how we attempt to keep the Wiki usable.

I wrote the article with the intention of helping other librarians who may be experiencing similar staff operations and project management pains but who may not have a large budget to invest in technologies to address these problems. I'm interested in hearing what others have done in similar situations, so if you have observations to speak of, please feel free to leave a comment here.