~~~~~

… or month or year or however long it takes to figure this out. And I offer a nice meal (more than a bowl of soup) to anyone who can solve or inspire me to solve this problem.

I attended a great presentation today at TechColumbus with Rich Hoeg of Honeywell. The topic was “Successful utilization of Web 2.0 and Social Networking Tools Within the Corporate Environment” and though the subject is anyway of general interest to me, I specifically went to see if I could find an answer to something that has been a pain point.

Now, I know that web2.0/ enterprise2.0 is all about being organic, collaborative and less rigid. (Sometimes I think I should write a book on it, in fact – because I haven’t seen a resource yet that really addresses the intersection of enterprise2.0 with regulations or standards.) And I’m totally on board with agile processes and embracing change in the middle of a project. But plain and simple, there does need to be a controlled version of this “thing” you’re creating – unless you’re creating a bowl of jello.

So here’s the problem in the most tangible terms I can muster:
Say we’re using a wiki within a project team to collaborate on the requirements for a new product. The wiki does version control each change, and each contribution is, in effect, a review record – so we have a controlled document and a review – easy, quick, organic (and compliant.) And at some point in the collaborative process, we get to a point where we all more or less agree that we’re on the same page about the requirements (or product definition, or design, or whatever the deliverable is..) Once we have reached that place of agreement, ideas continue to flow. And they may or may not be incorporated into the product.

Like this:

So at those points of consensus, we need to be able to point to this ever-changing collaborative ‘document’ and say, “This is what we agreed to” (for now.) And as collaboration continues and new points of consensus are reached, we adjust our plans and say, “Now this is what we’re doing.” .. and that change process can be formal or informal

So to summarize the question:
Within the tool itself (in my case, MediaWiki) how do you guide a consumer of that information to the version of the wiki page that represents the ideas that have formal agreement? As more ideas are contributed on a wiki page, and some of those ideas may not gain acceptance, we want to direct users to a previous version of the page that we agreed was our end product. (until the time comes that we agree that a later version is our end product.)

Without using cut & paste or saving a snapshot to another medium, how can this be done? Lunch or dinner awaits…

.. erm, that is – how can this be done easily by the end user, without a lot of clicking and BS? Wiki extensions would be great, as long as the process to the end user is as simple as a page edit – with a simple tag, perhaps.

Earlier posts on Enterprise2.0

Collaboration is easy to defend – but how is E2.0 collaboration adding value to the type of collaboration that already existed?

In-person collaboration is great when a high-performance team gets together. Awe-inspiring, even. But it doesn’t need to stand alone! In a collaborative session, no matter how democratic you try to be, some people naturally dominate the discussion. Some people do their best thinking after they’ve had time to digest, process and create. Some people are more creative in the morning, or in the evening.

Combining in-person collaboration with web-based tools like message boards or wikis extends the collaboration past the time constraints of the face to face meeting.

Case in Point: In the current program I manage, we meet regularly to brainstorm ideas and impact analyses. As we meet, we document the meeting in a wiki while projecting it on the wall. Everyone can see what we’re agreeing to (or not) and that exact record can be updated later by any participant (or absent team member) to include additional thoughts.

So how is that any different from a good ol’ document? It’s in the name: wiki. Wiki doesn’t mean ‘collaborate’ or ’social’- it means ‘quick’. The value of the wiki is that we can quickly author documents and quickly make updates and revisions without the cumbersome checkout/checkin process. *

Result: Documentation is up to date. We find that documents are much more often accurate because the tool doesn’t get in the way of the process.

*There does exist some debate about document control with a tool that allows for easy change. While a wiki does save history, it doesn’t easily permit an “official” version of the document to be the document of record. Collaboration is easy on a wiki – but putting a stake in the ground is not so simple. Our solution to this at the moment is to take a snapshot of the wiki when it is at the state of being ‘complete’ or ‘agreed-to terms’- and we upload it to a controlled repository. It isn’t a perfect solution, but it isn’t that unwieldy and the extra steps are worth the added value of using the wiki.

Have you ever written a document that no one read? Even if the first paragraph conveys “what’s in it for me?” it’s still a tough sell to get people to see what’s in it for them. Document walkthroughs and formal reviews can help twist people’s arms so they read a document, but you generally get limited attention and superficial involvement.

By getting people involved early in contributing content, they will be much more compelled and invested in the development process – even if it’s only to see where their ideas made an impact. Access to the process is the selling point in stoking interest.