September 22, 2010

Advising Work Teams on Blog Projects

I noticed that I have been advising teams on blogging a lot lately, and in listening to myself talk, I decided that I know, or think I know, something about this, so here goes... If you are asked to weigh in (or, perhaps, even if you're not), here are some talking points to guide a content team toward better blog decision-making.

To blog or not to blog? Do not be afraid to ask someone to take a step back and more thoughtfully consider the decision to start a blog. You may find that people assume they should have one for their project or other misguided assumptions along the lines of "everybody's doing it." Have the conversation; the team may gain a lot just from being led through a thoughtful discussion about their current information outputs.

What will be this blog's focus? If there is not a topical focus, personal narrative structure, or unique point of view in the blog, the team may wish to redouble its efforts with current communications platforms rather than adding a blog. If the blog is meant to replace some other current output, such as a newsletter, have a conversation about whether the exact same content will be shared via a blog. This is a good opportunity to talk about blogging as both/either a genre or a technology. The team may be considering blogging just because the mechanics are easier than something they are currently using, or they may be looking to personalize their content a bit more--both good reasons for choosing to blog, but the team may not have given this any thought and may be headed down a path of repeating much of what is available on your website.

How will we build an audience for this blog? The team has probably done some work to promote (and get readers used to) other forms of communication. Do not let them assume that those constituents will just slide right over to their blog. This point is larger than just the learning curve that may be an obstacle for some members of your audience; it also has to do with building interest in the new focus of the blog, if it has one, as well as getting readers used to using comments features. (In fact, you may be dealing with a project that wants to start a blog but never even considered the comments feature...which is a whole discussion in itself.)

How will we sustain an audience for this blog? You may fulfill the important role of 'cautionary tale,' or helping people put the breaks on if they haven't fully thought this through. There will be a lot of genuine enthusiasm among some people about starting a blog, but they should resist the initial excitement and channel it into a solid long-term plan for evaluation and follow-up after a test phase. They should also think about posting to the blog for a while as practice, and slowly releasing the content to larger and larger circles, starting with internal staff (although they may heartily resist staying in any sort of "Beta" phase).

*Who will do it? This is not as simple as it sounds. It may be a team effort of people contributing posts and/or content for sidebars, even if the blog appears to be coming from a director or project leader. Everyone can help, but have a clear division of labor chart that indicates who is doing what, by when, and who the back-up person is for each task. If there are going to be multiple authors, or guest bloggers, hammer out the details of how this will work.

How often? A team may think they have to blog every day to be effective. It all depends on the focus and scope. A monthly entry may be appropriate depending on the project. Posting at regular intervals is more important than posting often. In fact, advise teams to have a white board (electronic or otherwise) to help continually plan the next series of posts, which helps people resist the urge to post something as soon as they think of it.

How will the blog integrate with our current web presence? If you have a website, or a portion of one, for this project, and you are adding in a blog, be careful. If the sites co-refer, do this strategically. If one of the goals of the blog is to get people back to your website, then do that, and do not re-post on your blog everything that is available on your website. Think about what the process will look like when new content arises and everyone is sitting in a meeting trying to decide if it should be posted on the website, the blog, both or neither.

How will we integrate the blog into our overall information/communications strategy? This is the part where you inventory all the current outputs and make sure any overlap is strategic. If you Tweet, will you Tweet the new blog posts? Is the blog replacing another current task or are additional staff and resources required? Will you use the blog to draw attention to new publications and then link back to your website? Will you discuss publications on the blog and is the blog one of your publications? What policies, such as web accessibility or company approval, that govern other communications need to be applied to the blog? If your stakeholders will think you are pushing out too much information, are the tools you're using customizable so people can select how much they want to get?

Should we use a stand-alone blogging platform? Platforms like Blogger are great, and easy to use, but there may be a clear advantage to using your own system if it keeps people on your website (or it may be a policy not to use an outside platform for official communication). Your content management system may also have built-in tools for blogging, but these may or may not make subscriptions easy for readers to unify with the other blogs they read. There are probably advantages and disadvantages either way--explore them.

What will be the role of the librarian? This is a great time for you to step up the kind of services you offer any team you're embedded with. If you are involved from the beginning with any sort of blog project, you can think about things like archiving the posts on your own server (if there is a concern about that), cataloging the entries (if applicable), and helping with tech support and troubleshooting if you know the selected software.

If you engage people on these points and they say something like, "Let's not overthink this; it's only a blog," be ready to point out (very diplomatically) the flaw in this approach. You need only point to a few abandoned and/or inactive blogs to show what can happen if people do not undertake blogging decisions with the same rigor they would a print publication. A colleague of mine once said, "There is no exact recipe for success, but there are known ways to fail." Be a resource to all the potential bloggers on your staff so their work, with your help, will be successful.

No comments: