Friday, September 06, 2002

Why Johnny Can't Klog..

Why don't people write?

Fear.

Fear of failure.

Fear of criticism.

Fear of reprisal.

Fear of looking stupid.

Fear of removing all doubt.

Fear of permanence.

Fear of strangers.

Fear of invaded privacy.

Fear of falling behind.

Fear of the blank page.

 

 

Motive. 

I'm thinking a lot about folks who haven't written a paragraph since high school. Folks who never got more than a C in English. Paralyzed by a blank sheet of paper. By permanence.

Ask the blogger population their average and highest grades in English. Then ask the general working population.

Ask bloggers how many books they read last year. Compare to the rest of the public.

Ask bloggers how many words in the longest text they wrote in school, at work, or for fun. Then ask the general public.

You get my point.

The previous thread: Tekrite to Alison Fish of Blogfish to Sébastien Paquet to Al Macintyre

Pete Harbeson shared some lessons from deploying an enterprise klogging tool. One of them:

Most people don't like to write. We've had a difficult time designing interfaces that encourage adding information instead of just reading.

Ron Lusk said:

Some folks may not like to write because:

    • It is a public display of facility they may not feel they have, and may not have; one correspondent was afraid his spelling was bad.
    • It makes folly as clear as wisdom, but is more persistent than a comment made in the hall
    • It takes time and thought (and a little hubrisper Larry Wall) to put words out for others, and to make them—and think them—good enough for public consumption.
    • I'm sure more ideas will come to me, later...enough folly for now.

Seb's Open Research:

Lessons learned from a large scale K-logging implementation.

      • Most people don't like to write. We've had a difficult time designing interfaces that encourage adding information instead of just reading.
      • There's no substitute for good, accessible writing. We have several people who write consistently for the system. The logs show that postings from one writer get far more attention and prompt far more linking than those from the other writers.

Alison Fish of Blogfish:

I suspect that beginning bloggers and kloggers are often inhibited..

If we set up a k-logging community for our company intranet, I suspect there will be an initial _hump_ of hesitation among the employees. Maybe having a few designated posters at the beginning would ease the transition. Must think on this.

Al Macintyre's prescription:

  • Recruit co-workers who you think share your enthusiasm for the idea of having a KLOG on the company intranet, and would be good power users to serve as a kind of help desk and cheerleader squad when you launch it. [see: Klogging Roles and the klogspace editor]
  • With them, setup a system patterned on dws.Radio.FAQ model to discuss what needs resolution before implementing this, and inviting in the mass of users, so as to maximize odds of getting great value out of his project.
    • Do so outside company intranet until you nailed down everything needed for implementation.
    • That includes both technical know how and management approval.
    • When management says Yes, they often expect results soon.
    • So you use this outside discussion area to identify pre-requisites and get them resolved.
  • Assuming you are the moderator
    • Your team use a Category name like Radio Plot Twists which performs role like Radio Questions input to dws
    • Your aggregation, like dws.Radio.FAQ, have name like The Plot Thickens
    • Ask your co-workers if y"all want to invite into your discussion any non-employees from outside the firm
      • Think Radio enthusiasts who have written relevant documentation
      • Think other firms personnel trying to organize an company KLOG in which those people are not in competition with your company
  • Just as dws has Topic headings like
    • Radio Wishes
    • Radio Tips
    • Radio Questions
    • Radio Alerts
  • Your multi-author discussion would have its relevant Topic headings like
    • Documentation and Tutorial Flow Chart of Learning Curve
      • Topics that co-workers need to learn to be proficient in this.
      • Will you want to host a seminar class to help people get up to speed
      • Will you want to mirror some Radio documentation on your intranet
    • Examples of KLOGS worth emulating
      • Initially you just want anything that illustrates the concept
      • Then you want some that are close to what you want for your company
    • Implementation Challenges to Solve
      • What OS does Radio Frontier etc. work on
      • What OS are most heavily in use at your company
      • People working from home PC and from work PC updating from either location
    • Management Personnel Topics
      • Distinct from documentation for users and Implementation issues
      • This will eat some disk space and other resources
      • There will be executives slow to accept some communication methods
        • Everyone still needs to communicate with them by their preferred methods
        • Paper, Fax, e-mail, whatever
[a klog apart]
9:54:15 AM    

Blog your Project Status Flash Reports for communicating up..

Reporting a project's status upward shouldn't take more than 5 minutes. The technique is to boil everything down to a well structured, bullet-heavy, one-pager you can forward weekly or monthly.

Be sure you can back up what you report with more detail.

Flash reports, if timely and shared electronically, can eliminate a program management round-table meeting every week. Attendees x payrate x meeting length x 52; you do the math. Even with meetings, you get faster, more focused meetings.  

The simple version:

Project Status for the Month of ___________

Project Title: Project Name

Project Description: (A short paragraph: just enough to refresh the memory)

Accomplishments:

  • Planned and unplanned deliverables completed

Schedule Status:

  • Plan vs. Actual. Threats to schedule. Revisions, if any.

Upcoming Tasks:

  • Just a handful of the biggies.

Issues:

  • The short list: risks and issues worthy of escalation, and monitoring.

Depending on your reporting style, consider this more detailed version. Remember, we're communicating up.

Project Status Report

Project Name: Project Name / Code

Period: Start date thru end date (Week Number)

Project Manager: Project Manager's Name, phone, email, home url

Accomplishments this Period:

  • List accomplishments this period as bullets.

Scheduled Items Not Completed:

  • List items/targets missed in this reporting period as bullets.

Activities Next Period:

  • List proposed activities for next period as bullets.

Issues:

  • Reference any new issues identified this period from the Project Issues Log.
  • Reference any resolved issues this period from the Project Issues Log.

Changes to Stage Schedule:

  • Identify any predicted slippage to the schedule end of stage date.
  • List causes of slippage.
  • Specify corrective action.

Author contact info: name, home url, project home, report permalink

Flash Reporting Tips:

  1. Create a channel or category for each project's upward communication. This should be an access controlled web site: you'll be reporting personnel issues and bad news on occasion. Not necessarily for the whole team's eyes.
  2. Email a copy of your flash report to your project sponsors, including a permalink.
  3. Use a post title when you blog your report, making it easier to find. "Project Name - Flash Report - Week Starting 7/7/2004" lets you organize different reports
  4. You rarely fit everything on one page, but force yourself. Prioritizing your messages assures sponsor attention to things that matter most to you.

 

[a klog apart]
9:48:58 AM    

Keyless klogging for the rest of us..

David Gammel suggests...

Perhaps we should enable the writers to write and find another way for the others.

Absolutely.

A few approaches come to mind.

  1. Capture experiences and thoughts differently.
    • Photo/caption.
    • Video blog.
    • Hand drawings and notes.
      • Pencil to paper to scanner to blog, wacom to blog, whiteboard reader to blog, Photoshop to blog.
    • Enclosures of work product.
      • Use your blog to chronicle each Office document you finish, each AutoCAD drawing.
    • Music blog.
      • Perform, edit midi and samples, save to blog.
      • Newsreaders become music readers, feeds enqued to a tightly coupled WinAmp. 
    • Emails of note.
      • Not just a forward button but a Post-to-Blog button. Suddenly on the record.
    • Audio interviews.
      • Talk freely with someone, into the microphone please. Save to blog. Just key the metadata.
    • Scanned handwriting.
      • Fax to blog. Might be handy in parts of the world with limited access to computers. For those languages where handwriting is almost as fast (or faster) and more expressive than a keyboard. Captures doodles too.  
    • Dictation via handheld recorder.
      • Audio plus machine transcription.
    • Voice mail to blog.
      • Handy, accessible everywhere.
    • SMS to blog.
      • For the thumbs generation.
    • GPS blog.
      • Do you make housecalls? Drive the kids all over the place? Field reports? Your mobile follows you through the day. A quick SMS logs your stops/visits, perhaps a voice annotation. Blogging tool generates a map of the day, overlay of the week/month/year, posts by location, posts by proximity. I can't wait to see what happens with blogrolls, community services, where am I now, and just-in-time meetup. 
    • Proxy.
      • "Jim, can you blog this flanistam problem for me?"

  2. Prompt with Structure.
  3. True/False
    is easier than
    Multiple choice
    is easier than
    Fill in the blank
    is easier than
    an essay.

    When you fear a blank page, sometimes it helps if someone guides you.

    One way is with questions.

    • Pick a theme.
    • Deliver ad hoc or on a repeated schedule.
    • Prompt via enterprise calendar, email web form, or IM reminder.
    • Enter via web form.

    Consider:

    The Friday Five helps you develop your writing voice and add human depth to your blog. But teams and enterprises want other content to support operational and strategic goals.

    • By project, flash reports. Maybe even assignments.
    • Time sheets.
    • Professional development ("What did you learn this week?", "Who did you meet for the first time?", "What are you reading?")
    • Performance management (Weekly goals, accomplishments, concerns, and objectives for next week)
    • Process support. Polling for product proposal feedback, for example.  

    Manage these feeds like subscriptions to opt-in mailing lists. Moderators needed.

    Tech note: While not required, it would be handy to extend the metablogger API and RSS to support added schema to refine a post's data and metadata. 

  4. Enterprise system streaming.

For every human prompt, the information systems in a mid-sized enterprise cook up a dozen review-worthy items. Every step in the life cycle of a process or transaction is running through your ERP, accounting systems, recruiting system, SFA/CRM, network monitoring and management system, and your KM tools. They usually stay buried.

Your klogging tool can collect personalized alerts and notices from all these systems, organized for your quick scan. See something blogworthy? Flag it to your blog. Have an observation on the process, on progress, on quality, on results? Jot a note.

Posts include links back to the transaction in the web app. 

Machine prompts for blogging:

  • Increase transparency.
  • Capture the human experience of impersonal systems.
  • Provide opportunities for structured input back to the originating system.
  • Help people narrate processes.

See also: Whither blogs? 

[aka klogs]

[a klog apart]
9:46:51 AM