Future Changes

Why Businesses Don’t Collaborate: #3 Chaotic Group Input

Why Businesses Don't Collaborate: Chaotic Group Input

This is the third in a twelve-part series exploring Why Businesses Don’t Collaborate.
The full research report is available for Why Businesses Don't Collaborate Download.

Question

How many of the emails you receive require your direct input or feedback on the contents of an attachment?

Survey Comments

  • Almost all require my input. I am the editor for all the member and provider communications that are generated from our department. I also respond to RFPs on behalf of our department.
  • If I do get attachments, the sender usually wants my opinion on something before that sender does the official ‘mass mailing’.
  • Those that don’t require my direct input or feedback often need to be available as references and so need sorting and tracking to keep up with updated versions.
  • I myself have discovered that a useful way of obtaining feedback when I have specific questions about an in-process project is to attach an excerpt of a PDF with Acrobat comments embedded. This gets me excellent results — much better than if I simply point the recipient to the PDF and indicate which pages I want them to examine.

No Comments

Leave a Comment

Future Changes is written and published by Stewart Mader | Bio.
WIKIPATTERNS
A Practical Guide to Improving Productivity and Collaboration in Your Organization
  • Amazon.com
  • 800-CEO-READ
  • Free Chapter
  • Wikipatterns book: a practical guide to improving productivity and collaboration in your organization

    USING WIKI IN EDUCATION
    Case Studies from the Classroom
  • Amazon.com
  • Lulu Press
  • Examples & Resources
  • Using Wiki in Education wiki book


    Loading
  • Enterprise Wiki Software Guide - Tools & Capabilities
  • Why Businesses Don't Collaborate - Research Report
  • 21 Days of Wiki Adoption - Video Series
  • 8 Things You Can Do With an Enterprise Wiki
  • Key Components of an IT Project Team
  • Timeless Patterns of Technology Adoption
  • Failure to Launch: Factors Behind Stalled Adoption
  • How to do a Better Job of Project Collaboration
  • Geometrica: ISO 9001 Certification With a Wiki
  • When is a Wiki a Tool, and When is it a Medium?
  • Guess What: It is About the Tools
  • When Starting a Wiki, Don’t Forget Design
  • Wikis in .edu: Teaching Students to Share Knowledge
  • Interview: The State of Wikis in Education
  • Would You Pay 5¢ to Read This Article?




  • BARNRAISING WORKSHOPS
    A BarnRaising is a planned event that I use to help teams get started using the wiki. I start by having people look at examples of social software use in organizations to help focus their thinking on how it can help them, then identify specific workflows or business processes they want to improve. During the half-day workshop, the team gets its workspace set-up, structured, and seeded with content directly tied to the uses they've identified, so that when they return to their day-to-day work, the tool is embedded into their day-to-day workflow.



    PILOT, POLICY & PATTERNS
    I can work with your team to define project scope, assess cultural readiness, create policies and procedures, run a pilot, and manage large-scale deployment. I recommend developing a procedure to handle requests for new workspaces, a scalable naming convention, data retention policy, and careful communication policy. I’ll help you define content and workspace structure, develop templates and procedures for seeding the wiki with content, and migrate information to the wiki from tools that will be deprecated as a result of this project.

    Based on our information gathering, we’ll compile a list of people and groups who should be involved in the pilot phase. As their use gets underway, I’ll advise them as needed, assess their progress, and suggest refinements. To prepare for large-scale adoption and use, we’ll analyze usage patterns from pilot groups, identify critical integration and performance issues and recommend solutions. We’ll also capture anecdotes and examples to share with other groups during broader adoption.



    RETURN ON ADOPTION (ROA)
    I measure success in terms of Return on Adoption (ROA). This means that we take more into account than just the financial investment, and look at metrics that can’t easily be manipulated or give “red herring” results. For example, we'll look at the average number of edits and comments on pages, and based on content types (referential, workflow, project, etc.), and business units, because these directly indicate the level or participation by employees. Trends, or patterns, in these figures over time help to assess the pace of adoption, where usage is most active, and where we need to spend more time guiding people.




    Recommended Websites